Elektronická pošta

Vznik elektronické pošty se datuje do 70. let minulého století, kdy v roce 1965 vznikl na MIT program MAIL. Ten byl vyvíjen pro operační systém CTSS (Compatible Time-Sharing System), což bylo systém pro tehdejší sálové počítače. Účelem programu bylo sdílet informace jiným způsobem než vytvářením souborů (TO_NAME.ext) ve sdíleném adresáři. [1]. Dalším impulzem pro vývoj mailové komunikace bylo sdílený informací mezi univerzitami, které byly součástí první sítě ARPANET. Cílem bylo navrhnout takový standard, který by byl portabilní napříč různými systémy. [2]. Tuto roli splňoval SMTP (Simple Mail Transfer Protocol), který byl definován v roce 1982 (RFC 821). Roku 1995 vznikla extenze ESMTP (RFC 1869 - Extended Simple Mail Transfer Protocol). Další aktualizace se zavádí roku 2008 RFC 5321, v kterém bylo SMTP a ESMTP sjednoceno. Rovněž byla přidána úprava, která lépe přizpůsobuje protokol do mobilního prostředí. Poslední aktualizace proběhla v červnu 2015, kdy dříve experimentální RFC 1846 z roku 1995 je po úpravě zavedeno jako standard RFC 7504 a RFC 7505. Tyto standardy řeší problém neexistence MX záznamů pro doménu, která nepřijímá maily.

Quote:
"Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies."RFC 7505

Princip fungování služby

Email agenti - MUA,MTA,MDA, MSA

MUA - Aplikace/Proces koncového uživatele, který zařizuje komunikaci při autentizaci a zasílání/doručení mail zpráv (elm, exmh, mutt).

MSA - Přijímá zprávy přimo od MUA. V případě, že zpráva splňuje podmínky k odeslání na MTA
tzn. proběhla autentizace nebo zpráva nebyla vyfiltrována (proto ESMTP)RFC 4409

MTA - Uchovává zprávy na serveru (případně separované uložiště), vyřizuje jejich zasílání na další relay (=MTA) agenty. (sendmail, qmail, exim)

MDA - Doručuje zprávy aplikaci koncového uživatele MUA. Používá protokoly POP3,IMAP. (mail,procmail,deliver)

Quote:
At one time, every Email Service Provider (ESP) had its own protocols, and could not exchange messages with other ESPs. This forced users to pay for multiple accounts, one at each ESP having a Recipient to whom they would like to send a message. These proprietary protocols have now been replaced by three universal standards, SMTP, POP, and IMAP.[3]

Formát zpráv [4]

Zpráva je složena z obálky a samostatných dat. Obálku zprávy tvoří:

Obálkový odesílatel
Obálkový adresát

Obálku generuje MUA, z kterého se zasílá mail, následně je směrována přes relay agenty až ke koncovému MDA. To buď email doručí nebo generuje chybovou zprávu, kterou zasílá zpět Obálkovému odesílateli. MDA se vůbec do obsahu zprávy nedívá. Z hlediska bezpečnosti Obálkové adresy nemohou být podvrženy. Adresy uvnitř hlaviček zpráv mohou být podvrženy a v případě spamu také většinou jsou, nelze se tedy na ně spoléhat.[5]

Data jsou rozdělena do dvou částí:

Hlavička - obsahuje řídící informace

Jednotlivé hlavičky mají tvar "klíč: hodnota".
Řádky ve tvaru ' 'hodnota jsou pokračováním hodnoty z předchozího řádku.
Hlavičky mohou obsahovat pouze ascii znaky s výjimkou CR (0x0D) a LF (0x0A), ty se mohou vyskytovat pouze pohromadě CRLF ve významu ukončení řádku.


Hlavička při odeslání zprávy:

Received: by sender-daemon@arethusa2.fi.muni.cz
        PID 1369 for pv090@fi.muni.cz@mail.muni.cz; Tue, 10 Oct 2017 10:11:30 +0200
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Mailer: MIME-tools 5.502 (Entity 5.502)
MIME-Version: 1.0
From: "Jiří Šácha" <409861@mail.muni.cz>
To: pv090@fi.muni.cz
Subject: referat - Elektronická pošta
X-Ismu-Affiliation: stud FI MU
X-Ismu-WWW-Page: http://is.muni.cz/osoba/409861
X-Ismu-WWW-Auth-Page: https://is.muni.cz/auth/osoba/409861
X-Ismu-Interface: v2
Message-ID: <1507623070-409861-14.2022350978088-61475@mail.muni.cz>
Date: Tue, 10 Oct 2017 10:11:10 +0200
Content-Length: 94
Return-Path: 409861@mail.muni.cz
X-ISMU-Expires: 2018-10-10

Hlavička při příjmu zprávy:

Received: by receive-deliver@arethusa2.fi.muni.cz
        PID 7613 for 409861@mail.muni.cz; Tue, 10 Oct 2017 14:56:25 +0200
Return-Path: 
Delivered-To: 409861@mail.muni.cz
Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3])
	by arethusa2.fi.muni.cz (Postfix) with ESMTPS id B1FCC1E214F
	for <409861@mail.muni.cz>; Tue, 10 Oct 2017 14:56:24 +0200 (CEST)
Received: by anxur.fi.muni.cz (Postfix, from userid 11561)
	id AD5C6606AA; Tue, 10 Oct 2017 14:56:24 +0200 (CEST)
Date: Tue, 10 Oct 2017 14:56:24 +0200
From: Jan Kasprzak 
To: Jiří Šácha <409861@mail.muni.cz>
Cc: pv090@fi.muni.cz
Subject: Re: referat - Elektronická pošta
Message-ID: <20171010125624.GK166635@fi.muni.cz>
References: <1507623070-409861-14.2022350978088-61475@mail.muni.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1507623070-409861-14.2022350978088-61475@mail.muni.cz>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DSPAM-Result: Whitelisted
X-DSPAM-Processed: Tue Oct 10 14:56:25 2017
X-DSPAM-Confidence: 0.7013
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 59dcc379212351428728810

Problém:
Jak řešit kódování, když jsou v hlavičce povoleny jen non-ASCII znaky?
"=?charset?encoding?encoded-text?="
"=?utf-8?Q?hello?=" (příklad) [7]

Tělo zpráv - obsahuje samotný text nebo jiný datový obsah

odděleno od hlavičky prázdným řádkem
nelze zasílat raw data, je nutné je překódovat z důvod výskytu cr lf v obsahu
Content-Transfer-Encoding: 8-bit (US-ASCII znaky)
Content-Transfer-Encoding: Base64 (konverze do textu)

MIME (Multipurpose Internet Mail Extensions):[6] [8]

Umožňuje kódování těla zpráv, které obsahují non-ASCII znaky. Definován v RFC 5322

MIME format: specifikuje verzi MIME
Content-transfer-encoding: kódování dat v těle zprávy
Content-type:

text/plain,htmml,richtext
image/gif,jpeg,g3fax
audio/basic
video/mpeg,quicktime
application/octet-stream,postscript,pdf
multipart/mixed,parallel,alternative

Content-Disposition: pomocí tohoto klíče se specifikují soubory v příloze

Přílohy můžeme specifikovat jako inline a non-inline. Klíč Content type lze specifikovat vícekrát, definujeme hranice (boundaries).

"Content-type: multipart/related" (Inline příloha)
"Content-type: multipart/mixed" (Non-inline příloha)

Protokoly

SMTP

Protokol SMTP slouží k výměně emailových zpráv mezi dvěma koncovými uzly za využítí protokolu IP. Ke komunikaci mezi vnitřními uzly MTA->MTA využívá port 25. V případě, že to struktura podporuje, klient zasílá emaily na port 587 prvku MSA, který vyřizuje správnost emailu před jeho samotným odesláním. Spojení mohou být šifrována pomocí TLS (SMTPS jako port 465), a nebo pomocí speciální typu zprávy STARTTLS. Komunikace probíhá na základě výměny textových zpráv a jejich odpovědí mezi klientem a serverem, případně vniřními prvky po cestě k příjemci zprávy.

Příklad komunikace

K otestování správně nastaveného SMTP serveru s otevřeným portem 25, můžeme využít telnet.


$ telnet example.org 25
S: 220 example.org ESMTP Sendmail 8.13.1/8.13.1; Wed, 30 Aug 2006 07:36:42 -0400
C: HELO mailout1.phrednet.com
S: 250 example.org Hello ip068.subnet71.gci-net.com [216.183.71.68], pleased to meet you
C: MAIL FROM:
S: 250 2.1.0 ... Sender ok
C: RCPT TO:
S: 250 2.1.5 ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
From: Dave\r\nTo: Test Recipient\r\nSubject: SPAM SPAM SPAM\r\n\r\nThis is message 1 from our test script.\r\n.\r\n
S: 250 2.0.0 k7TKIBYb024731 Message accepted for delivery
C: QUIT
S: 221 2.0.0 example.org closing connection 
Connection closed by foreign host.
$

příklad komunikace SMTP

Příkazy

SMTP Commands

HELO
EHLO
AUTH
FROM
RCPT
MAIL
DATA
RSET
VRFY
EXPN
HELP
NOOP
ETRN

ETRN

PIPELINING
SIZE
QUIT

Quote:
I do not recommend implementing EXPN. RFC 1123 says that EXPN is useful for ``diagnosing inadvertent mail loops.'' This is obsolete; modern mailing lists stop loops automatically. The primary use of EXPN today is by spammers collecting addresses. There is an EXPN extension that promises support for the EXPN verb. Many servers support EXPN but don't announce the EXPN extension. Clients don't pay attention to the EXPN extension; they simply try the EXPN request. cr.yp.to

2XY - Success

4XY - Persistent transient failure

5XY - Permament failure

Aktuální přehled o návratových kódech v RFC 5248 - A Registry for SMTP Enhanced Mail System Status Codes

POP3 (Post Office Protocol)

IMAP (Internet Mail Access Protocol)

Způsob ukládáná zpráv[12]

Jakmile dorazí zpráva k cílovému MTA, přebírá ji MDA. Ten ji ukládá ve formátu:

mailbox (mbox)

kvůli zamykání může mít problém s výkonem
složitější kvůli práci nad soubory narozdíl od maildir
více klientů nemůže přistupovat ke stejnému mailboxu
Netscape, Mozilla Thunderbird (využívají také mail klienti)

maildir[11]

každá zpráva se uchovává v separátním souboru s unikátním jménem
výlučný přístup ke zprávám je zaručen pomocí zamykání
pro každého uživatele udržuje podsložky tmp, new, cur
minimum zamykání
více klientů může přistupovat ke stejné složce
Kmail, Mailx, Mutt, GNUMail, Balsa, Cone (využívají také mail klienti)

Quote:
"Maildirs will not scale very well on servers that use old, slow, hardware. Maildirs will also do poorly with an inefficient filesystem that stores very large folders which are frequently searched for specific content. However maildirs' performance should be adequate even on slow machines with very large folders, as long as the mail activity is just occasional read/write access, and browsing. Even with large folders, containing unread messages, maildirs will require less system load than mboxes. On fast hardware, these benchmarks indicate that maildirs scale better in more often than not. Maildirs scale much better with mail folders that contain large messages. Even with folders that have a large number of smaller messages, maildirs did better than mboxes on many benchmarks." Performance test maildir vs. mbox

Spam

Nevyžádaná pošta, aktuálně v Q1,Q2 2017 je 57% provozu spam.[13] V dřívějších letech i 90%. Velký podíl na tom mají open mail relay servery, které umožňují komukoli odeslat/přijímat email, bez toho aniž by ověřili že odesílatel/příjemce je z lokální domény. Útočníci pravidelně skenují internet pro nalezení takových serverů. Techniky používané proti spamu:

Blacklisting - databáze open-relay serverů, IP adresy takových serverů jsou zveřejněné skrze DNS. Server zprávu odmítá nebo zařazuje do složky SPAM. Databáze je veřejná online na DNSBL.info
Greylisting - metoda, kdy SMTP server automaticky odmítá každý email od odesílatele, kterého nezná
Delayed bounce - zpráva o oznámení nedoručení emailu (DSN) je uměle zpožděna. Využití při forgingu Return-Path [14]
SPF (Sender Policy Framework) - systém pro detekci podvržených zpráv. Identita odesílatele zprávy je ověřena pomocí DNS záznamů typu TXT. (ověří se že uživatel je z lokální dmény, kterou spravuje mail server) [15]

Quote:
"SPF má fatální problém. Pokud máte nastavené přeposílání mailů, pošta odchází z nového serveru, ale ten není uveden v SPF DNS záznamu." Jak spammerum zabranit falšovat adresy

DKIM - narozdíl od SPF používá certifikát a elektronický podpis. Do hlavičky emailu se přidává tzv. DKIM-Signature, který obsahuje elektronický podpis generovaný SMTP serverem odesílatele. Veřejná část klíče je uložena v DNS jako TXT záznam.
Spam Assasin - antispamový filter, který využívá mechanismy jako Bayesovské filtrování, analýzu hlaviček a těla emailu, DNS blacklist a různé databáze pro filtrování spamu (Spam Assasin)

Implementace pošty

Nejpoužívanější implementace pošty jsou[16]:

Exim - 56% (MTA)
Postfix - 33% (MTA)
Sendmail - 5% (MTA)
MAilEnable - 3% (MTA)
MDaemon - 1% (MTA)

Dovecot (MDA - IMAP/POP3 server)

Quote:
"In March 2017 in a study performed by E-Soft, Inc.,[3] approximately 33% of the publicly reachable mail-servers on the Internet ran Postfix."

Postfix a jeho konfigurace[17][18][19]

(=VMailer, =IBM Secure Mailer) - SMTP aplikace, nezajišťuje doručení POP/IMAP3. Vznikl jako open source nástroj, který řeší nedostatky Sendmailu. Modulární návrh, kdy jednotlivé procesy běží s jinými oprávněními. Lepší zabezpečení, spolehlivost a výkon než Sendmail

Konfigurační soubory master.cf, main.cf typicky v /etc/postfix

master.cf - definuje, které služby mají být zapnuté a definuje jejich chování
main.cf - definuje hlavní konfiguraci postfix

mydomain - doména SMTP serveru
myorigin - přidá se v případě, že odesílatel nespecifikoval v mailové adrese svou doménu (většinou nastavena na $mydomain)
myhostname - jmená adresa smtp serveru
inet_interfaces - síťové rozhraní na kterých SMTP poslouchá
inet_protocols - definuje IPv4/IPv6 verzi
mynetworks - síťový rozsah IP adres pro které má SMTP služba fungovat
relayhost - specifikuje doménu serveru (nebo jen doménu) kam se bude pošta směrovat
smtpd_recipient_restrictions - výchozí nastavení povoluje službu pouze pokud je příjemce z mynetworks
smtpd_client_restrictions - definuje restrikční pravidla pro klienty

po změně konfiguračních souborů nutný restart služby (cmd: postfix restart)

Pomocné nástroje

postconf - konfigurační nástroj postfix
postqueue - umožňuje základní operace s frontou zpráv v případě, že nejdou doručit
postsuper - silnější nástroj na ovládání fronty

DNS MX záznamy

Používají se v případě, že přijemce definovaný v obálce emailu má email ve tvaru user@example.org, kde pomocí DNS se vyhledá doménové jméno stroje, který provozuje mail službu pro doménu "example.org"


@       IN      MX      10      mail.example.org

MX record dokumentace Následně pro doménové jméno mail.example.org musí existovat A/AAAA záznam, který mapuje doménové jména na IPv4/IPv6 adresy.

Quote:
"Some mailservers will not trust mail coming from your server unless they can do a reverse DNS lookup. This takes two possible forms. Most mailservers care that a PTR record exists at all. Strict mailservers do a forward lookup on the name your mailserver introduces itself as such as mail.example.com, verify it is the IP address that is read off the connection, and do a PTR lookup on that IP address to see if it resolves to the same name." "[21]