SPF v praksi: popis vseh pošiljateljev

Modul 4: Dostavljivost: SPF, DKIM in DMARC v praksi · Čas branja: 12 minut

Cilj lekcije: Po tej lekciji boste znali odkriti vse storitve, ki pošiljajo e-pošto v imenu Vaše domene, jih združiti v en sam zapis SPF, rekurzivno prešteti poizvedbe do meje deset, in zavestno izbrati med ~all in -all.

Ključni pojmi: popis pošiljateljev, ovojni pošiljatelj (Return-Path), en sam zapis SPF, include, redirect, omejitev 10 DNS-poizvedb (RFC 7208, odstavek 4.6.4), prazne poizvedbe (void lookups, največ 2), rekurzivno štetje, permerror, sploščenje (flattening), SPF za poddomene, SPF na domeni, ki ne pošilja pošte, ~all in -all

Kratka ponovitev

Zapis SPF je zapis TXT na Vaši domeni, ki se začne z v=spf1 in navaja, kateri strežniki smejo pošiljati e-pošto v imenu Vaše domene. Zgradba, znaki + - ~ ? in tri najpogostejše napake (dva zapisa, +all, več kot deset poizvedb) so opisani v tečaju DNS, lekcija 4.3. Če Vam je SPF nov pojem, to najprej preberite. Ta lekcija obravnava zahtevnejši del: v praksi skoraj nihče natančno ne ve, kdo vse pošilja pošto v imenu njegove domene.

Korak 1: popis

SPF deluje le, če so v njem navedeni vsi pošiljatelji. Če enega pozabite, bo njegova pošta pristala v neželeni pošti ali bo zavrnjena, takoj ko zaostrite DMARC. Zato preglejte ta seznam. Pri povprečnem majhnem podjetju jih hitro najdete pet ali šest:

Dva dobra načina, da jih odkrijete:

1. Branje glav sporočil. Iz vsakega sistema si pošljite sporočilo (račun, obnovitev gesla, testni novičnik) in v glavah preverite Return-Path in Authentication-Results (lekcija 1.5). Tam vidite, prek katere domene in katerega strežnika je sporočilo prišlo.
2. Poročila DMARC. Nastavite DMARC na p=none z naslovom za poročila (lekcija 4.4). Po nekaj tednih boste v poročilih (lekcija 4.5) videli vsak strežnik, ki je pošiljal pošto v imenu Vaše domene, tudi tistega, na katerega ste pozabili. To je najzanesljivejši popis.

Ne spada vsaka storitev v Vaš SPF

Tu se pogosto zalomi. SPF preverja ovojnega pošiljatelja (Return-Path), ne naslova Od. Mnoge storitve za novičnike in pošiljanje pošiljajo z Return-Path na svoji lastni domeni, na primer bounce-123@mail.mailer.example. Prejemnik v tem primeru preveri zapis SPF domene mailer.example, ne Vašega. Vnos include te storitve v Vašem zapisu v tem primeru ne naredi ničesar, le stane Vas eno poizvedbo.

Kar ta storitev potrebuje, da uspešno prestane DMARC, je podpis DKIM z Vašo domeno (lekcija 4.3) ali lasten poddomeno Return-Path, ki ga določite Vi (na primer bounce.example.com kot CNAME na storitev). Zato v navodilih storitve preverite, kaj zahteva. Če piše "vnesite include: v svoj SPF", to storite. Če piše le "ustvarite te zapise CNAME za DKIM in domeno za povratna sporočila (bounce)", potem v Vaš glavni zapis ni treba dodati ničesar. Modul 7 to obravnava podrobneje.

Korak 2: en zapis, in pravilno štetje

Vsi pošiljatelji gredo v en zapis. Recimo, da Vaš popis pokaže naslednje: poštni strežnik Vašega ponudnika gostovanja, Microsoft 365 za nekaj zaposlenih, Vaš računovodski program in podporno službo (helpdesk). Zapis potem izgleda na primer takole:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Koliko poizvedb je to? Preštejte vsak a, mx, include, exists, ptr in redirect, in nato preštejte tudi vse, kar je navedeno v zapisih za vsakim include:

Pri 11 prejemnik vrne permerror: celoten zapis SPF se potem ne upošteva, za nobenega pošiljatelja. Pošta z Vašega lastnega poštnega strežnika je torej slabše ocenjena, ker podporna služba stane tri poizvedbe. Zahrbtno pri tem je, da je lahko Vaš zapis danes 9, jutri pa 11, ne da bi Vi karkoli spremenili, ker neka storitev razširi svoj lasten zapis.

Poleg tega: največ dve prazni poizvedbi

RFC 7208 omenja tudi void lookups: poizvedbe, ki ne vrnejo ničesar (ime ne obstaja ali nima zapisa SPF ali naslovnega zapisa). Več kot dve taki poizvedbi prav tako povzročita permerror. To se dogaja predvsem s starimi vnosi include storitev, ki jih ne uporabljate več in so odstranile svoj zapis, ali z a:, ki kaže na strežnik, ki ne obstaja več. Torej počistite.

Korak 3: nazaj pod deset

Če ste nad deset, obstajajo štiri rešitve, od najboljše do najslabše:

1. Odstranite, kar ni potrebno. Storitve, ki jih ne uporabljate več. Storitve, ki pošiljajo z lastnim Return-Path (glejte zgoraj) in zato ne spadajo v Vaš SPF. a, če Vaše spletno mesto samo ne pošilja e-pošte. mx, če Vaš MX kaže na storitev, ki je že vnesena z include v Vašem zapisu.
2. Uporabite poddomeno. Dovolite storitvi, da pošilja z nieuws.example.com ali factuur.example.com. Ta poddomena dobi lasten zapis SPF samo za to storitev in se ne všteva v deset Vaše glavne domene. Uskladitev (alignment) v DMARC (lekcija 4.4) privzeto deluje tudi za poddomene.
3. Uporabite ip4: in ip6: za svoje lastne stalne strežnike. Ti ne stanejo nobene poizvedbe. To storite le za naslove, ki jih upravljate sami in se ne spreminjajo.
4. Sploščenje (flattening) (zamenjava vseh vnosov include z IP-naslovi, ki trenutno stojijo za njimi). To zniža število na 0, vendar zapis ni več pravilen, takoj ko storitev spremeni svoje naslove, velike storitve pa to počnejo redno. To storite le z orodjem, ki to samodejno vzdržuje, ali še bolje, sploh ne.

redirect ali include?

redirect= pomeni: uporabi zapis SPF druge domene namesto tega zapisa. Stane eno poizvedbo, enako kot include. Priročno je, če imate veliko domen, ki morajo imeti popolnoma enako politiko: v=spf1 redirect=_spf.example.com na vsaki domeni, dejanski zapis pa na enem mestu. Zapis z redirect= ne sme imeti all, saj se v tem primeru redirect prezre. Gmail to uporablja sam: gmail.com ima v=spf1 redirect=_spf.google.com.

Korak 4: ~all ali -all?

Priporočilo tega tečaja, enako kot v tečaju DNS:

• Začnite z ~all (softfail). Pošta s strežnika, ki ni v Vašem zapisu, se obravnava kot sumljiva, vendar običajno ni takoj zavrnjena. Če pozabite na pošiljatelja, je škoda omejena.
• Preidite na -all (fail), ko ste prepričani, da so vsi pošiljatelji navedeni, na primer potem ko ste nekaj tednov spremljali poročila DMARC in ni več neznanih virov.

Z DMARC poleg tega je razlika manjša, kot se pogosto misli. DMARC odloča na podlagi "SPF ali DKIM uspešen in usklajen". Softfail za DMARC pomeni preprosto "neuspešno". Prava zaščita torej prihaja iz strogega pravilnika DMARC, ne iz -all. Nekateri prejemniki pri -all zavrnejo sporočilo že pred oceno DMARC; to je razlog, da -all izberete šele, ko je Vaš zapis res popoln.

Domena, ki nikoli ne pošilja pošte

Imate domene, ki nikoli ne pošiljajo e-pošte (staro blagovno znamko, domeno za tipkarske napake)? Zaščitite jih pred zlorabo z naslednjim:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Tu je -all takoj pravilen: nihče ne sme pošiljati pošte. Zadnja vrstica je null MX (RFC 7505): "ta domena ne prejema pošte". example.com sama je nastavljena natanko tako.

V praksi: tako je videti v nadzorni plošči

Pri gostiteljskem paketu WebOké privzeto velja v=spf1 a mx include:webawere.nl ~all. Če dodate storitev, ta zapis prilagodite (v DirectAdmin: DNS Management, svinčnik za zapisom SPF, polje Vključiti domeno; v Mojem WebOké: pomočnik za SPF na zavihku DNS). Pustite include:webawere.nl, dokler Vaša pošta ali spletno mesto tečeta prek teh strežnikov. Pri drugih ponudnikih se privzeti include imenuje drugače, vendar je načelo enako: dopolnite, ne ustvarjajte drugega zapisa.

Povzetek

• Najprej naredite popis vseh pošiljateljev; pri tem pomagajo poročila DMARC in glave sporočil.
• Storitev z lastnim Return-Path ne spada v Vaš SPF; ta potrebuje DKIM z Vašo domeno.
• Štejte rekurzivno: vsak include, a, mx, exists, ptr in redirect, tudi znotraj include. Nad deset, ali več kot dve prazni poizvedbi, pomeni permerror.
• Vrnite se pod deset tako, da počistite in uporabite poddomene; sploščenje (flattening) le s samodejnim vzdrževanjem.
• Začnite z ~all, preidite na -all, ko ste prepričani. Domene, ki nikoli ne pošiljajo pošte: -all, DMARC reject in null MX.

Kviz

Naloga

Naloga Z4.2: Rekurzivno štetje SPF Vaše domene. Vnesite svojo lastno domeno (ali sidn.nl, če nimate lastne domene). Najprej sami preštejte, koliko DNS-poizvedb stane zapis SPF, vključno z vsem znotraj include, in vnesite številko, skupaj s koncem zapisa (~all, -all, ?all ali +all). Program sproti preveri, vključno s praznimi poizvedbami, in prikaže drevo.

Naloga O4.2: Vaš popis pošiljateljev. S tabelo iz te lekcije sestavite seznam vseh sistemov, ki v imenu Vaše domene pošiljajo e-pošto. Pri vsakem navedite: prek katerega strežnika ali storitve, ali mora biti v Vašem SPF (lasten Return-Path ali ne) in ali podpisuje DKIM z Vašo domeno. Iz vsaj dveh sistemov si pošljite testno sporočilo in iz glav sporočila zabeležite domeno Return-Path in domeno DKIM (d=).

Za nadaljnje branje

Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih deluje podobno.

• Brezplačen tečaj DNS 4.3: SPF: kdo sme pošiljati pošto v imenu Vaše domene?
• Priročnik DirectAdmin 5.7: Nastavitev in dopolnitev zapisa SPF
• Kako deluje zapis SPF v DNS? Zapis SPF (Sender Policy Framework) je poseben zapis TXT v DNS Vašega domena, ki določa, kateri strežniki smejo pošiljati e-pošto v imenu Vaše domene. S tem preprečite, da bi nepooblaščene osebe zlorabile Vaš domen za pošiljanje neželene ali lažne e-pošte. Ko prejemni strežnik prejme e-sporočilo, preveri zapis SPF Vašega domena v DNS. Na podlagi naslova IP pošiljatelja nato ugotovi, ali je ta strežnik v zapisu SPF naveden kot pooblaščen. Če ni, lahko prejemni strežnik e-sporočilo označi kot sumljivo ali ga celo zavrne. Primer zapisa SPF: v=spf1 include:_spf.{$domain} ~all V tem primeru: - v=spf1 pomeni, da gre za različico 1 protokola SPF. - include:_spf.{$domain} določa, da so strežniki, navedeni pri tem domenu, pooblaščeni za pošiljanje e-pošte. - ~all pomeni, da je treba e-sporočila iz drugih, nenavedenih virov obravnavati previdno (mehki neuspeh). Za pravilno delovanje je pomembno, da zapis SPF vključuje vse strežnike in storitve, ki dejansko pošiljajo e-pošto v imenu Vaše domene, na primer Vaš strežnik za spletno gostovanje, storitev za pošiljanje novic ali CRM sistem. Če zapis SPF ni pravilno nastavljen, lahko to povzroči, da Vaša e-sporočila pristanejo v mapi za neželeno pošto ali so popolnoma zavrnjena. Zapis SPF nastavite v nadzorni plošči DNS Vašega domena pri WebOké.
• Dodajanje ali sprememba zapisa SPF v DirectAdminu
• Priročnik WebOké 5.5: DNS-pomočniki: MX, SPF, DMARC, CAA in SRV
• RFC 7208 (SPF), odstavek 4.6.4 (omejitve) in 6.1 (redirect); RFC 7505 (null MX)