Cadru de politici ale expeditorului

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Gramatică de corectat!
Acest articol sau secțiune despre informatică conține erori de ortografie sau sintactice sau este scris într-o formă îmbunătățită .
Comentariu : Intrarea are pasaje neclare, probabil rezultatul unei traduceri imperfecte
Ajutați la corectarea acestuia în conformitate cu convențiile din limba italiană și manualul de stil Wikipedia . Urmați sfaturile de proiectare de referință .

Sender Policy Framework ( SPF ) este un sistem de validare a e-mailului conceput pentru a detecta încercările de falsificare a e-mailurilor . Sistemul oferă administratorilor unui domeniu de e-mail un mecanism care le permite să definească gazdele autorizate să trimită mesaje din acel domeniu, permițând destinatarului să verifice validitatea acestora. [1] Lista gazdelor autorizate să trimită e-mailuri pentru un anumit domeniu este publicată în Domain Name System (DNS) pentru domeniul respectiv, sub formă de înregistrări TXT formatate special. Phishingul , și uneori chiar spamul , utilizează adrese false ale expeditorului, astfel încât postarea și verificarea înregistrărilor SPF pot fi considerate parțial o tehnică anti-spam. Cadrul de politici pentru expeditor este definit în publicația IETF RFC 7208 .

Istorie

Conceptul din spatele SPF a fost menționat pentru prima dată în 2000, [2] dar nu a fost până în 2002, când Dana Valerie Lank a publicat, indiferent de prima mențiune, un proiect al specificației SPF pe lista de discuții IETF „namedroppers”. A doua zi, Paul Vixie a postat propria sa versiune a specificației SPF pe aceeași listă. Aceste publicații au trezit mult interes, ducând în cele din urmă la înființarea Grupului de cercetare anti-spam (ASRG) și a listei de corespondență corespunzătoare, unde ideea SPF a fost discutată de un grup de abonați care părea să crească. zilnic. Printre propunerile prezentate ASGR s-au numărat cele din „Reverse MX” al lui Hadmut Danisch și „Designated Mailer Protocol” al lui Gordon Fecyk. [3]

În iunie 2003, Meng Weng Wong a fuzionat specificațiile RMX și DMP [4] cu modificările sugerate de alți programatori. În următoarele șase luni, s-au făcut un număr mare de modificări și o comunitate numeroasă a început să lucreze la SPF. [5]

SPF a fost inițial menit să însemne expeditor autorizat și uneori a fost denumit și SMTP + SPF, dar în februarie 2004 numele său a fost schimbat în actualul cadru de politici ale expeditorului.

La începutul anului 2004, IETF a creat grupul de lucru MARID și a reunit propunerile SPF ale ASRG și CallerID ale Microsoft, folosindu-le ca bază pentru ceea ce este acum cunoscut sub numele de ID expeditor . După eșecul MARID, comunitatea SPF a revenit la versiunea originală a SPF și, în iulie 2005, prima versiune a specificației a fost aprobată de IESG ca experiment IETF: comunitatea a fost invitată să observe și să studieze SPF în următoarele doi ani.până la publicare. La 28 aprilie 2006, SPF RFC a fost publicat sub numele de Experimental RFC 4408 .

Principiile de funcționare

Simple Mail Transfer Protocol permite oricărui computer să trimită e-mailuri fără a verifica expeditorul: mesajul poate pretinde că provine de la orice adresă sursă. Acest lucru permite utilizatorilor de spam să folosească adrese de e-mail false, ceea ce face mai dificilă urmărirea originii unui mesaj și mai ușor să-și ascundă adevărata identitate pentru a-și evita responsabilitățile. Utilizarea adreselor de expeditor falsificate permite mesajelor de phishing să păcălească destinatarii să dezvăluie informații private ca răspuns la un e-mail trimis presupus de o organizație de renume, cum ar fi o bancă sau alt furnizor legitim de servicii.

SPF permite proprietarului unui domeniu să definească reguli pentru identificarea serverelor autorizate să trimită e-mailuri cu adresa expeditorului în acel domeniu, utilizând înregistrări TXT corespunzătoare sistemului de nume de domeniu (DNS). Destinatarii pot compara originea mesajului cu regulile SPF și, în caz de probleme, pot decide să respingă mesajele primite din surse neautorizate chiar înainte de a primi conținutul mesajului. Prin urmare, principiile de funcționare sunt similare cu cele din „listele de găuri negre bazate pe DNS” ( DNSBL ), cu excepția faptului că SPF utilizează schema de delegare a autorităților aparținând sistemului de nume de domeniu. Practica actuală necesită utilizarea înregistrărilor TXT, [6] la fel ca în implementările timpurii. În primele etape ale definiției, un nou tip de înregistrare (SPF, tip 99) a fost înregistrat și pus la dispoziție, iar utilizarea înregistrărilor TXT pentru SPF a fost propusă ca un mecanism alternativ de compatibilitate pentru software-ul DNS care nu îl suporta. RFC experimental RFC 4408 a declarat în secțiunea 3.1.1 că „un nume de domeniu conform SPF ar trebui să aibă înregistrările SPF ale ambelor tipuri de RR”. [7] Standardul RFC 7208 propus afirmă că „utilizarea tipurilor alternative de DNS RR a fost susținută în faza experimentală a SPF, dar a fost ulterior depreciată”. [6]

Adresa expeditorului este transmisă la începutul dialogului SMTP, în plic . Dacă serverul de poștă electronică verifică faptul că acest domeniu nu poate proveni de la acel client, acesta poate comunica un mesaj de respingere, determinând generarea unui „ mesaj de respingere ” la adresa expeditorului original. Cu toate acestea, SPF nu împiedică falsificarea adresei expeditorului indicată în corpul mesajului. Spammerii pot trimite apoi e-mailuri care pot trece verificarea SPF, dacă au un cont pe un domeniu cu o politică de expeditor validă sau pot profita de un sistem compromis. Cu toate acestea, acest lucru face ca spamul să fie mai ușor de identificat.

Principalul avantaj al SPF este că proprietarii de adrese de e-mail care au fost folosite ca expeditori falsați nu primesc cantități mari de mesaje de eroare nedorite și alte răspunsuri automate. Dacă acei destinatari utilizează SPF pentru a specifica care sunt sursele legitime ale mesajelor lor, receptorii pot respinge imediat mesajele false, reducând sau eliminând astfel retrodifuzarea .

SPF are potențial alte avantaje dincolo de a ajuta la identificarea e-mailurilor nedorite. Mai exact, dacă un expeditor furnizează informații SPF, receptorii pot utiliza rezultatele SPF pozitive în combinație cu o listă albă pentru a identifica expeditorii de încredere cunoscuți. Scenarii precum sistemele compromise și / sau utilizatorii care trimit e-mailuri partajate limitează acest tip de utilizare.

Motive pentru implementare

Dacă un domeniu publică o înregistrare SPF, spammerii și phisherii au mai puține șanse să trimită e-mailuri care pretind că provin din acel domeniu, deoarece e-mailurile falsificate sunt mai susceptibile de a fi capturate de filtrele de spam. Prin urmare, un domeniu SPF protejat este mai puțin interesant pentru spammeri și phishers ca „adresă falsificată”. Aceasta înseamnă că adresa este mai puțin probabil să fie listată pe lista neagră de filtrele de spam și, prin urmare, crește în cele din urmă probabilitatea ca un e-mail legitim să fie livrat și să nu fie victima falsului pozitiv al filtrelor. [8]

FAIL și redirecționare

SPF previne redirecționarea simplă a mesajelor . Atunci când un domeniu publică o politică SPF restrictivă, mesajele legitime trimise destinatarilor prin redirecționarea e-mailului către o terță parte pot fi respinse sau respinse dacă toate următoarele sunt adevărate:

  1. expeditorul mesajului nu rescrie calea de returnare .
  2. următorul hop nu are expeditorul în lista sa albă.
  3. hopul efectuează o verificare SPF.

Aceasta este o caracteristică necesară și evidentă a SPF: comenzile din spatele „limitei” destinatarului MTA ( MX ) pot funcționa numai direct.

Oricine publică o politică SPF trebuie să accepte riscul ca e-mailurile legitime să fie respinse dacă nu respectă politica definită. Acesta este motivul pentru care este indicat să efectuați teste până când sunteți mulțumit de rezultate.

Test HELO

Pentru o cale de returnare goală utilizată în mesajele de eroare și alte răspunsuri automate, este necesară o verificare SPF a identității HELO.

Cu o identitate falsă HELO, rezultatul NONE nu ajută, dar pentru numele de gazdă SPF valide protejează identitatea HELO. Această caracteristică SPF a fost întotdeauna acceptată ca opțiune pentru destinatari, iar schemele SPF ulterioare, inclusiv specificația finală, recomandă să verificați întotdeauna HELO.

Acest lucru permite destinatarilor să introducă pe lista albă anumiți expeditori, pe baza unui HELO PASS, sau să respingă toate e-mailurile după un HELO FAIL. Acest mecanism poate fi utilizat și în „sistemele de reputație” ( sistemul de reputație , orice listă albă sau neagră este un caz simplu de sistem de reputație).

Implementare

Respectarea SPF constă din 3 sarcini conexe:

  • Publicați o politică : domeniile și gazdele identifică mașinile autorizate să trimită e-mail în numele lor. Acestea fac acest lucru adăugând înregistrări suplimentare la informațiile lor DNS existente: orice domeniu sau nume de gazdă care are o înregistrare de tip A ( o înregistrare A ) sau o înregistrare MX ( înregistrare MX ) ar trebui să aibă o înregistrare SPF care să specifice politica sa dacă este utilizată într-un e-mail adresa și / sau ca argument HELO / EHLO. Gazdele care nu sunt trimise prin e-mail ar trebui să aibă o înregistrare SPF publicată care să indice așa ceva („v = spf1 –tot”). Acest lucru este foarte recomandat pentru a valida înregistrarea SPF folosind instrumente de testare a înregistrărilor, cum ar fi cele furnizate pe pagina web a proiectului SPF .
  • Verificați și utilizați informațiile SPF : destinatarii folosesc interogări DNS obișnuite și simple, care sunt de obicei memorate în cache pentru a crește performanța. Destinatarii apoi interpretează informațiile SPF așa cum sunt specificate și acționează asupra rezultatului obținut.
  • Revizuiți și, dacă este necesar, corectați redirecționarea e-mailurilor : redirecționarea e- mailurilor „formatate” nu este permisă de SPF. Alternativele sunt:
    • Remailing (adică înlocuirea expeditorului original cu unul aparținând domeniului local);
    • Refuz (respingere, adică răspunsul 551 User not local; please try <[email protected]> );
    • Listă albă , adică plasarea serverului țintă într-o listă albă, astfel încât în ​​viitor să nu mai respingă un mesaj redirecționat;
    • Sender Rewriting Scheme , un mecanism mai complicat care manipulează notificările de rutare de la livrare către serverul de origine.

Prin urmare, problema cheie din SPF constă în specificarea noilor informații DNS pe care seturile de domeniu și destinatar le utilizează. Înregistrările de mai jos sunt scrise utilizând sintaxa DNS tipică:

 example.com. IN TXT "v = spf1 ip4: 192.0.2.0/24 ip4: 198.51.100.123 a -all"

"v =" definește versiunea SPF utilizată. Următoarele cuvinte oferă mecanismele de utilizat pentru a determina dacă un domeniu este eligibil pentru a trimite e-mailuri. „ip4” și „a” specifică sistemele cărora li se permite să trimită mesaje pentru domeniul dat. „- all” de la sfârșit specifică faptul că, dacă mecanismul nou definit nu a produs rezultate, mesajul ar trebui respins.

Mecanisme

Sunt definite opt mecanisme :

ANEXĂ se potrivește întotdeauna cu adrese; utilizat pentru rezultatele implicite, cum ar fi -toate pentru toate adresele IP care nu s-au potrivit prin mecanismele anterioare.
LA Dacă numele de domeniu are o înregistrare de adresă (A sau AAAA) care poate fi „rezolvată” la adresa expeditorului, aceasta se potrivește.
IP4 Dacă expeditorul se află într-un anumit interval de adrese IPV4 , acesta se potrivește.
IP6 Dacă expeditorul se află într-un anumit interval de adrese IPV6 , acesta se potrivește.
MX Dacă numele de domeniu are o înregistrare MX în rezoluția adresei expeditorului, acesta se potrivește (adică e-mailul ajunge de la unul dintre serverele de e-mail primite ale domeniului)
PTR Dacă numele domeniului ( înregistrarea PRT ) pentru adresa clientului este prezent în domeniul dat, iar acel nume de domeniu „se rezolvă” la adresa clientului ( DNS invers confirmat înainte ), acesta se potrivește. Acest mecanism a fost învechit și nu ar mai trebui utilizat. [6]
EXISTĂ Dacă numele de domeniu dat „se rezolvă” la orice adresă, se potrivește (indiferent de adresa la care se rezolvă). Acest mecanism este rar folosit. Împreună cu limbajul macro SPF, oferă potriviri mai complexe, cum ar fi interogări DNSBL .
INCLUDE Se referă la politica unui alt domeniu. Dacă politica acestui alt domeniu este acceptabilă, mecanismul este aprobat / acceptabil. Cu toate acestea, dacă politica nou inclusă eșuează, procesarea continuă. Pentru a delega complet mecanismul către o altă politică de domeniu, trebuie utilizată extensia „redirecționare”.

Calificări

Fiecare mecanism poate fi combinat cu unul din cele patru calificative :

  • + pentru un rezultat PASS (test trecut). Poate fi omis; de exemplu + mx este echivalent cu mx .
  • ? pentru un rezultat NEUTRU (neutru), care este interpretat ca NICI (fără politică).
  • ~ (tilde) pentru un rezultat SOFTFAIL, destinat ca ajutor de depanare, un rezultat intermediar între NEUTRU și FAIL. De obicei, mesajele care returnează un SOFTFAIL ca rezultat sunt acceptate, dar etichetate.
  • - (minus) pentru un rezultat FAIL, e-mailul trebuie respins (vezi mai jos).

Modificatori

Modificatorii sunt concepuți pentru a permite extinderi viitoare ale cadrului. Până în prezent, doar doi modificatori definiți în RFC 4408 au fost distribuiți pe scară largă:

  • exp = some.example.com returnează numele unui domeniu cu o înregistrare DNS TXT (interpretată folosind macrocomanda de limbaj SPF) pentru a obține o explicație pentru rezultatele FAIL - de obicei aceasta este o adresă URL care este atașată la codul eroare SMTP . Această caracteristică este rar utilizată.
  • redirect = some.example.com poate fi utilizat în locul mecanismului ALL pentru a vă conecta la înregistrarea politicii unui alt domeniu. Acest modificator este mai ușor de înțeles decât mecanismul similar INCLUDE.

Eroare de manipulare

De îndată ce implementările SPF detectează erori de sintaxă într-o politică de expeditor, trebuie să înceteze evaluarea și să returneze PERMERROR ca rezultat. Prin omiterea mecanismelor greșite care nu pot funcționa așa cum era de așteptat, în consecință include și : bad.example și redirect = bad.example provoacă o PERMER.

O altă protecție este maximum zece mecanisme de interogare DNS, adică orice mecanism cu excepția IP4, IP6 și ALL. Implementările pot opri evaluarea SOFTERROR atunci când durează prea mult sau o interogare DNS expiră (expiră), dar trebuie să returneze PERMERROR dacă politica are nevoie, direct sau indirect, de mai mult de zece interogări pentru mecanisme. Fiecare redirecționare = se bazează și pe această limită de procesare.

O politică tipică SPF HELO v = spf1 a -all poate efectua până la trei interogări DNS: (1) TXT, (2) SPF (depășit de RFC 7208 ) și (3) A sau AAAA. Această ultimă interogare este considerată primul mecanism către limita de 10. În acest exemplu, este și ultimul, deoarece ALL nu are nevoie de căutare DNS.

Dispute

În 2004, Steven M. Bellovin a scris un e-mail adresându-se preocupărilor sale legate de SPF. [9] Unele dintre acestea includ:

  • SPF a folosit inițial înregistrări TXT în DNS, care ar trebui să fie text în formă liberă, fără semantică atașată. Avocații SPF au recunoscut în liniște că ar fi fost mai bine să existe înregistrări special desemnate pentru SPF, dar această alegere a fost făcută pentru a permite implementarea rapidă a SPF. În iulie 2005, IANA a acordat SPF Record Record Return Type. Ulterior, utilizarea înregistrărilor SPF a fost întreruptă și, începând din 2016, este încă necesară utilizarea înregistrărilor TXT. [6]
  • La momentul în care și-a scris mesajul, nu a existat un consens că SPF este calea corectă de urmat. Unii dintre principalii furnizori de servicii de e-mail nu l-au introdus în acest sistem. Cu excepția cazului în care și până când o fac, nu va ajuta prea mult, nici pentru clienții lor (care reprezintă o parte substanțială a populației de utilizatori), nici pentru oricine altcineva (deoarece adresele lor ar putea fi falsificate). Este demn de remarcat faptul că, deoarece această preocupare a fost ridicată, Google Mail și AOL, printre altele, au îmbrățișat SPF. [10]
  • Preocupările puternice ale lui Bellowin erau legate de ipotezele din spatele SPF („modelul său semantic”). Atunci când se utilizează SPF, înregistrările DNS SPF determină modul în care unui expeditor i se permite să trimită mesaje, ceea ce înseamnă că este sarcina proprietarului domeniului să controleze modul în care expeditorilor li se permite să trimită mesaje. Persoanelor care utilizează adrese de e-mail „portabile” (cum ar fi adresele de e-mail create de organizații profesionale) li se va cere să utilizeze expeditorul SMTP al proprietarului domeniului, care poate sau nu să existe. Cu toate acestea, organizațiile care furnizează aceste adrese „portabile” își pot crea propriii agenți de trimitere a e-mailurilor (MSAS) ( RFC 6409 ) sau pot oferi VPN-uri sau pur și simplu nu publică o înregistrare SPF. De asemenea, SPF leagă SMTP Return-Path doar la MSA-urile permise; utilizatorii sunt încă liberi să-și folosească adresele RFC 5322 în altă parte.

Există și alte îngrijorări cu privire la impactul utilizării pe scară largă a SPF, în special impactul asupra diferitelor forme legitime de falsificare a e-mailurilor [11], cum ar fi serviciile de corespondență, utilizarea SMTP de către persoane cu identități multiple etc. (De exemplu, un persoană care folosește serverele SMTP ale ISP-ului la domiciliu pentru a trimite e-mailuri cu adresa de e-mail de la serviciu ca adresă). Pe de altă parte, multe dintre aceste utilizări pot fi „intenționate”, dar nu „legitime”. Într-o anumită măsură, aceasta este mai mult o chestiune de proprietate și așteptări decât o chestiune tehnică.

Grupul de lucru IETF spfbis, însărcinat cu refacerea specificației SPF prin vizarea statutului „Standarde propuse” într-un nou RFC, în aprilie 2013 părea să fi ajuns la un consens cu privire la deprecierea SPF tip 99 în favoarea utilizării continue a înregistrărilor TXT. [12] Oamenii din grupul de lucru DNSEXT s-au opus puternic acestui lucru într-o serie de discuții prin e-mail care acoperă spfbis, dnsext și discuția IETF în general. [13] [14] Șeful grupului de lucru spfbis a cerut încetarea acestui torent de proteste, deoarece discuția despre tipul de înregistrare (RRTYPE) în grupul de lucru fusese deja rezolvată cu mult timp în urmă [15] ( o mișcare care a fost văzută ca o încercare de a reduce la tăcere protestele unor niște feroci puristi DNS). Ulterior a fost propus un proiect independent, care documentează modul în care recurența falsă a înregistrărilor TXT caracterizează internetul curent. [16]

Distribuție

Software anti-spam precum SpamAssassin versiunea 3.0.0 și ASSP implementează SPF. Mulți agenți de transfer de e-mail (MTA) acceptă direct SPF, cum ar fi Courier , CommuniGate Pro, Wildcat , MDaemon și Microsoft Exchange ; sau aveți la dispoziție patch-uri sau plug-in-uri care acceptă SPF, inclusiv Postfix , Sendmail , Exim , qmail și Qpsmtpd . [17] Din 2013, peste șapte milioane de domenii publică SPF FAIL - toate politicile. [18]

În august 2005, s-a aflat că EarthLink nu va permite domeniilor găzduite posibilitatea de a insera înregistrări SPF. [19]

Într-un sondaj publicat în 2007, 5% din domeniile .com și .net au avut un fel de politică SPF. În 2009, un sondaj neîntrerupt al Nokia Research a raportat că 51% din domeniile testate au specificat o politică SPF. [20] Aceste rezultate pot include politici banale, cum ar fi v = spf1? Toate . [21] În aprilie 2007, BITS, o divizie a mesei rotunde pentru servicii financiare, a publicat recomandări de securitate a e-mailurilor pentru membrii săi, inclusiv distribuția SPF. [22]

În 2008, Grupul de lucru anti-abuz de mesagerie ( MAAWG ) a publicat un document legat de autentificarea prin e-mail, care acoperă, de asemenea, partea referitoare la SPF, ID-ul expeditorului și MailKeys Identified Mail (DKIM). [23] În documentul „Sender Best Communication Practices”, MAAWG afirmă: „Cel puțin, expeditorii ar trebui să încorporeze înregistrări SPF pentru domeniile lor de e-mail”. [24]

Notă

  1. ^ Sender Policy Framework: Introducere , pe openspf.org . Adus la 14 iunie 2016 (arhivat din original la 17 iunie 2016) .
  2. ^ SPF: Prima mențiune publică 2000 , pe openspf.org . Adus la 28 august 2014 (arhivat din original la 30 ianuarie 2015) .
  3. ^ SPF: Istorie / Pre-SPF , pe openspf.org . Adus la 16 mai 2009 (arhivat din original la 16 iulie 2011) .
  4. ^ RMX și DMP comparate Arhivat la 25 aprilie 2008 la Internet Archive pentru o comparație între RMX, DMP și SPF. pe site-ul istoric al openspf.
  5. ^ SPF: History / SPF-2003 , pe openspf.org . Adus la 16 mai 2009 (arhivat din original la 18 ianuarie 2008) .
  6. ^ a b c d Scott Kitterman, Sender Policy Framework (SPF) pentru autorizarea utilizării domeniilor în e-mail, versiunea 1 , la tools.ietf.org , IETF , aprilie 2014. Accesat la 26 aprilie 2014 .
  7. ^ Wong, M. și W. Schlitt. RFC 4408, aprilie 2006
  8. ^ De ce ar trebui să implementez o înregistrare SPF pe domeniul meu? , la emailmanual.co.uk , Manual de e-mail, mai 2009. Accesat la 1 ianuarie 2010 (arhivat din original la 29 ianuarie 2010) .
  9. ^ Steve Bellovin exprimă îndoieli cu privire Filed 13 aprilie 2004 în Internet Archive . (Ianuarie 2004)
  10. ^ Informații SPF , la postmaster.aol.com , AOL Postmaster. Adus la 4 octombrie 2007 (arhivat de la adresa URL originală la 8 iulie 2007) .
  11. ^ Probleme cu expeditorul desemnat , la taugh.com , Taughannock Networks. Adus la 16 decembrie 2009 .
  12. ^ Murray Kucherawy, Resolution of the Sender Policy Framework (SPF) și Sender ID Experiments , la tools.ietf.org , IETF , iulie 2012. Accesat la 16 decembrie 2013 .
  13. ^ S. Moonesamy, Obsoleting SPF RRTYPE , DNSEXT Discussion List , IETF , 23 aprilie 2013. Accesat la 16 decembrie 2013 .
  14. ^ Dan Schlitt, Ultimul apel: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) pentru autorizarea utilizării domeniilor în e-mail, versiunea 1) la standardul propus , pe lista de discuții IETF , IETF , 29 August 2013. Adus 16 decembrie 2013 .
  15. ^ Andrew Sullivan, Subiectul RRTYPE . Lista de discuții SPFBIS , IETF , 29 mai 2013. Accesat la 16 decembrie 2013 .
  16. ^ John Klensin, Andrew SUllivan și Patrik Fältström, An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE , at tools.ietf.org , IETF , August 2013. Accesat 16 decembrie 2013 .
  17. ^ Qpsmtpd SPF plugin , pe github.com , 2013. Accesat la 14 iunie 2016 (arhivat din original la 29 iunie 2013) .
  18. ^ SPF- All Domain Survey , pe spf-all.com , 2013. Accesat pe 23 aprilie 2013 .
  19. ^ SPF Pierde Mindshare , la circleid.com , 2005. Accesat la 4 aprilie 2011 .
  20. ^ Raport de cercetare Nokia privind adoptarea SPF , pe Fit.Nokia.com , Nokia , 19 septembrie 2011. Accesat la 5 aprilie 2016 (arhivat din original la 20 septembrie 2011) .
  21. ^ Cricket Liu, Handicapping New DNS Extensions and Applications , onlamp.com , ONLamp, ianuarie 2007. Accesat la 4 octombrie 2007 .
  22. ^ BITS Email Security Toolkit ( PDF ), pe bitsinfo.org , BITS, aprilie 2007. Accesat la 13 iunie 2008 (arhivat din original la 15 mai 2008) .
  23. ^ Dave Crocker, Trust in Email Begins with Authentication ( PDF ), la maawg.org , MAAWG , martie 2008. Accesat la 28 iulie 2011 (arhivat din original la 29 ianuarie 2013) .
  24. ^ Rezumat executiv MAAWG Sender Best Practices Practices ( PDF ), pe maawg.org , MAAWG , 7 octombrie 2011. Accesat la 27 aprilie 2012 .

Elemente conexe

linkuri externe

Adus de la „ https://it.wikipedia.org/w/index.php?title=Sender_Policy_Framework&oldid=106893854 ”