# Mechanizmy weryfikacji nadawcy wiadomości

## SPF (Sender Policy Framework) ([RFC7208](https://tools.ietf.org/html/rfc7208))
Pozwala właścicielowi domeny zdefiniować adresy IP uprawnione do wysyłki maili. Sprawdzenie odbywa się na podstawie domeny obecnej w polu `MAIL FROM` wg. RFC5321(envelope) - `RFC5321.MailFrom`. Pole to jest też znane jako `Return-Path` czy `Envelope-Sender`. Jeśli `MailFrom` jest puste, tzw `null sender`, domena jest brana z komendy `HELO/EHLO`, tzw. `HELO identity`.

**Uwaga! SPF nie sprawdza pola From z nagłówka, tzw. `RFC5322.From`, które jest wyświetlane w klientach pocztowych, tylko `RFC5321.MailFrom`. SPF może przejść sprawdzenia poprawnie, nawet gdy pole From jest spoofowane.**

SPF jest definiowany w rekordzie TXT domeny która ma być chroniona. Serwer pocztowy który otrzymuje wiadomość, wysyła zapytanie o rekord dla domeny z pola `MAIL FROM (RFC5321.MailFrom)`, a następnie go analizuje.

Przykład rekordu dla `nask.pl`

dig txt nask.pl | grep v=spf1

nask.pl. 600 IN TXT "v=spf1 include:_spf.nask.pl include:_spf2.nask.pl     
ip4:195.187.245.33/24 ip4:193.59.201.32/27 ip4:193.59.201.64/27 
ip4:193.59.201.238/32 ip4:195.187.242.0/24 ip4:193.59.204.167/32 
ip4:194.181.0.106 ip4:194.181.0.102 ip4:195.187.6.28 -all"

Serwer pocztowy sprawdza czy adres IP klienta SMTP z którego został nadany, zawiera się na ostatecznej (po rozwiązaniu wszystkich składowych) liście dozwolnych adresów IP w rekordzie SPF.

#### Składowe rekordu SPF

* `v=spf1` - wersja SPF, jedyna obecnie wykorzystywana to 1
* `ip4:192.168.0.1` - Adres IPv4 uprawniony do wysyłki
* `a:google.com` - Domena jest rozwiązywana i jej rekord A dodawany jako uprawniony IP do wysyłki
* `mx:google.com` - Rekordy A dla MX dla podanej domeny dodawne są jako IP uprawnione do wysyłki. Gdy użyte jest samo `mx` sprawdzany jest MX domeny dla której aktualnie weryfikowana jest polityka
* `include:google.com` - Domena z której rekord spf zostanie również uwzględniony - dodany do obecnie weryfikowanych

Na końcu rekordu definiowana jest akcja co ma się stać z mailem jeśli nie będzie pasował do polityki:

| Dyrektywa | Nazwa | Opis |
| -------- | -------- | -------- |
| -all | Fail | Odrzuć |
| ~all | Softfail | Rekomenduj odrzucenie |
| +all | Pass | Akceptuj |
| ?all | Neutral | Nic nie sugeruj (Neutralne) |

**Uwaga** RFC w wielu miejscach mówi że coś powinno się robić, a nie że trzeba. Trzeba pamiętać że różne serwery pocztowe odbiorcy mogą różnie interpretować otrzymany rekord SPF. Np. wiele serwerów traktuje `-all` oraz `~all` tak samo.

Ograniczenia: Max długość rekordu to 255 znaków i max 10 rozwiązań domen ( występujące przy tagach: a, mx, ptr, include, exists), wliczając to rozwiązania rekursywne.

## DKIM (DomainKeys Identified Mail) ([RFC6376](https://tools.ietf.org/html/rfc6376))

Daje możliwość dodania do wiadomości podpisu (z body i wybranych pól nagłowka), który wykorzystując kryptografię asymetryczną może zostać zweryfikowany przez serwer odbiorcy za pomocą klucza publicznego z odpowiedniego rekordu DNS danej domeny.

Podpis jest dodawany do nagłówka wiadomości jako pole `DKIM-Signature`, przykład:

DKIM-Signature: 
v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncas.us-cert.gov; s=15q3; i=@ncas.us-cert.gov; h=Content-Transfer-Encoding:
Content-Type:x-subscriber:X-Accountcode:Errors-To:MIME-Version:
Message-ID:X-ReportingKey:Subject:Date:To:Reply-To:From; bh=bqWW
VsSFeYnMUseujsFFol8xU8ZRNz18EBcFtuxI91c=; b=hjQjcCOi/CzTr1STuUnN
digjN5gW2Wr81UR2CBKpwUV8MqYNlZV76YuGdX+T ...

ważne pola
* `d=` - Domena którą odpytać o klucz publiczny do odszyfrowania podpisu
* `s=` - Selector wskazujący który z opublikowanych kluczy publicznych ma być użyty
* `h=` - Jakie pola nagłówka zostały podpisane i mają zostać sprawdzone
* `a=` - Algorytm który został użyty do wyliczenia hasha (podpisu)
* `b=` - Zaszyfrowany podpis (hash wyliczony przez wysyłającego)

Klucz publiczny jest umieszczany w rekordzie TXT subdomeny zbudowanej z pól Selectora i Domeny nagłówka `DKIM-Signature`.
Np. `15q3._domainkey.ncas.us-cert.gov`
Gdzie `15q3` jest wartośćią pola `s`, `ncas.us-cert.gov` wartośćią pola `d`, a `_domainkey` stałe.

Po pobraniu klucza publicznego, pole `b` jest odszyfrowywane i otrzymany hash użyty w celu weryfikacji zgodności podpisu. Odbywa się to poprzez wyliczenie nowego hasha z aktualnego body oraz nagłówków i porównaniu go z otrzymanym.

Sam w sobie DKIM nie ma możliwości sugerowania co zrobić z wiadomością z niezgodnym podpisem, potrzebny do tego jest DMARC.

## DMARC (Domain-based Message Authentication, Reporting & Conformance) ([RFC7489](https://tools.ietf.org/html/rfc7489))

Zestaw reguł budowany na bazie SPF i DKIM pozwalający zdecydować czy wiadomość faktycznie przyszła od wysyłającego za którego się podaje. Jako centralny punkt odniesienia bierze pole `RFC5322.From` (widoczone w klientach pocztowych). Posiada też możliwości raportowania.

Sprawdzenia:
- SPF alignment - Czy SPF poprawnie przechodzi sprawdzenie **ORAZ** Czy`RFC5321.MailFrom` zgadza się z `RFC5322.From` (dla ustawień relax dowolne z pól może być subddomeną, dla strict domeny muszą być dokładnie takie same)
- DKIM alignment - Czy wiadomość jest poprawnie podpisana wg. DKIM **ORAZ** Czy wartość w polu `d=` nagłówka DKIM zgadza się z `RFC5322.From` (dla ustawień relax dowolne z pól może być subddomeną, dla strict domeny muszą być dokładnie takie same)

Dowolne ze sprawdzeń musi się zakończyć sukcesem żeby mail doszedł.

DMARC authentication pass = (SPF authentication pass AND SPF identifier alignment) OR (DKIM authentication pass AND DKIM identifier alignment)

W rekordzie TXT subdomeny `_dmarc`, dla domeny z pola`RFC5322.From`, umieszczony jest wpis definiujący reguły dopasowania, tzn. co zrobić z wiadomością gdy nie zostanie spełnione któreś ze sprawdzeń, oraz gdzie wysyłać raporty z powiadomień.
Np. gdyby w polu From było `abc.google.com` to o rekord odpytywany jest `_dmarc.abc.google.com`.
Jeśli nie ma tam poprawnego rekordu, pytana o niego jest domena narzędna, w tym przypadku `google.com`, więc kolejne zapytanie o rekord TXT pójdzie do domeny `_dmarc.google.com`

Przykład:

dig +short txt _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:[e-mail]"

Opis pól:
* `v=` - Wersja protokołu, musi być `DMARC1`
* `rua=` - Lista adresów na które mają przyjść raporty ze sprawdzeń - w formacie * `mailto:[e-mail]`
* `adkim=` - Ustawienia restrykcyjności dla DKIM - 'r' (Relaxed) lub 's' (Strict). W relaxed porównywane są tylko domeny narzędne (dopuszczalne są subdomeny). Domyślnie Relaxed.
* `aspf=` - Ustawienia restrykcyjności dla SPF - 'r' (Relaxed) lub 's' (Strict). W relaxed porównywane są tylko domeny narzędne (dopuszczalne są subdomeny). Domyślnie Relaxed.
* `p=` - Co ma się stać z wiadomocią która nie przejdzie sprawdzeń, możliwe opcje:

| Opcje dla `p=` | Opis |
| -------- | -------- |
| none | nie są podejmowane żadne akcje, tylko raportowanie |
| quarantine | wiadomość powinna zostać przeniesiona do spamu |
| reject | wiadomość powinna być odrzucona |

[Więcej możliwych pól](https://tools.ietf.org/pdf/rfc7489.pdf#39)