Lue tilapäivämäärä ennen ehdotuksen arviointia
Domain Relationship Policy Framework ehdottaa verkkotunnuksille tapaa kuvailla ja vahvistaa keskinäisiä suhteita. Tämä voisi antaa luottavalle osapuolelle selkeämpää tietoa kuin samanlainen logo, jaettu verkkosivuston suunnittelu tai päätelty yritysyhdistys. Se, vaikuttavatko tällaiset tiedot sähköpostipäätökseen, riippuu sen valtuudesta, validointisäännöistä ja kuluttajien käyttäytymisestä, ei pelkästään niiden julkaisemisesta.
Projektin tilasivu, tarkastettu 9. marraskuuta 2026, nimenomaisesti päivämäärän asemansa 1. heinäkuuta 2024. Siinä kuvataan ehdotettu puite julkista käsittelyä varten ja luetellaan kuvaava Internet-luonnos seuraavana vaiheena. Näiden päivämäärien on pysyttävä erillään: luettava sivu ei ole nykyinen tilailmoitus. Tätä arviointia varten ei ole varmistettu myöhempää lopullista projektin tilaa, standardien tulosta tai vastaanottajan hyväksyntää.
The projektin kotisivut kuvaa ad hoc -kehitystä ja kuittaa puuttuvat käyttöönottotiedot. A Helmikuu 2024 kehittäjätili, J. Trent Adams kutsuu myös työtä varhaiseksi ehdotukseksi. Sen kielenkäyttö standardoinnista tulisi lukea tässä yhteydessä. Tämä artikkeli arvioi tätä dokumentoitua mallia; se ei ilmoita toteutetusta standardista tai määrää tuotanto DNS tietueita.
Erottele löytömekanismi politiikan merkityksestä
Ehdotettu arkkitehtuuri sisältää pieniä DNS TXT -vahvistuksia ja tarvittaessa monipuolisempia käytäntödokumentteja. Väitteet voivat ilmaista perussuhteita tai auttaa löytämään yksityiskohtaisia käytäntöjä. Asiakirjat erottavat metatiedot politiikan sisällöstä ja mahdollistavat sanastojen kuvaamisen erilaisia suhteita. Suuri osa tulkkaustyöstä kuuluu luottavalle osapuolelle.
Se ero on tärkeä. Asiakirjan löytäminen ei osoita, että kaksi kuluttajaa tulkitsisivat sen sanastoa samalla tavalla. Kuluttaja tarvitsee arvioitavalle suhteelle sovitun profiilin, joka sisältää tuetut ehdot ja tuntemattomien ehtojen käyttäytymisen. Käytettävissä olevat sivut havainnollistavat mahdollisuuksia sen sijaan, että luotaisiin yksi täydellinen yhteentoimiva kielioppi. Heidän erilaisia kuvauksia vähimmäisväitteen sisällöstä ei pitäisi hiljaa ratkaista keksittyyn pakolliseen muotoon.
Yksi arkkitehtoninen selitys vaatii myös DNS pätevyyden. RFC 1035 kohdat 3.3 ja 3.3.14 määrittää TXT -tiedot yhdeksi tai useammaksi merkkijonoksi, joista jokaisen pituus on yksi okteti. 255 oktetin sisältöraja koskee yksittäistä merkkijonoa, ei yleistä 255 merkin enimmäispituutta koko TXT resurssitietueelle. Tämä korjaus ei anna DRPF:n puuttuvaa julkaisua tai jäsennysprofiilia.
Tarkastele vastavuoroista vahvistusta erityisenä väitteenä
Kehittäjätili kuvaa vahvistusta molempiin suuntiin: toisen verkkotunnuksen nimeävässä väitteessä tulee olla vastaava lausunto kyseisestä verkkotunnuksesta. Tämä kyseenalaistaa yksipuolisen assosiaatiovaatimuksen. Se ei vahvista itsenäisesti laillista omistajuutta, molempien järjestelmänvalvojien tilien eheyttä tai sähköpostissa saadun maksuohjeen turvallisuutta.
Arvioijan tulee tunnistaa, mitä viranomaista kukin julkaisija todella valvoo ja mitkä todisteet suojaavat hakua. Kaksi toistensa johdonmukaista lausuntoa vaarantuneista järjestelmistä ovat eri ongelma kuin yhden toimialueen esittäminen tuettomana väitteenä. Tietoturvatarkistus tarvitsee siksi uhkamallin, aitousoletukset ja määritellyn vikojen käsittelyn. Nämä ovat tässä arviointivaatimuksia, eivät ehdotuksen tai tämän artikkelin osalta testatun toteutuksen osoittamia ominaisuuksia.
Kartoita kuvitteellinen brändisuhde päästä päähän
Harkitse kuvitteellisia verkkotunnuksia brand.example ja parent.example . Brändin ylläpitäjä julkaisee alisteisen väitteen; pääjärjestelmänvalvoja julkaisee vastaavan vahvistuksen. Hypoteettinen turvallisuussovellus olisi kuluttaja. Sen ehdotettu tehtävä on verrata kahta kohdistettua lausetta samalle suhteelle pitäen samalla väitetyn liikesuhteen erillään viestin todentamisesta.
Projektin liittyvän verkkotunnuksen käyttötapaus kuvaa kahta löytötapaa. Kuluttaja voi löytää vanhemman vakuutuksen vanhemman vakuutuksesta tai seurata lapsen suoremmin toimittamaa vakuutuspaikkaa. Sivulla on myös strukturoitu JSON-LD-asiakirja. Nämä ovat käsitteellisiä esimerkkejä, eivät todisteita siitä, että nimetyt yritykset käyttävät DRPF:ää tai että niiden näytetarrat muodostavat vakaan lankamuodon.
Tätä kuvitteellista karttaa varten kuluttaja kirjaa, mitkä asiakirjat ja tulkinnat tukivat suhdetta tietyssä kohdassa. Jos vanhempi peruuttaisi vahvistuksen, suhteella ei enää olisi samaa keskinäistä tukea. Näille kuvitteellisille verkkotunnuksille ei ole julkaistu tai haettu tietueita, eikä jäsentäjää, allekirjoituksen vahvistusta tai luottavan osapuolen toimintaa ole testattu.
Vaadi elinkaarta, joka ylittää kyvyn vetäytyä
Arkkitehtuuri kuvaa suhteen katkaisemista muuttamalla sen vahvistusta. Se on hyödyllinen käsitteellinen peruutusmekanismi, mutta se ei takaa välitöntä peruuttamista kaikkialla. Välimuistissa olevat väitteet, säilytetyt käytäntöasiakirjat ja tilapäisesti poissa julkaisijat vaativat nimenomaista käsittelyä, ennen kuin kuluttaja voi tehdä luotettavia päätöksiä.
Arvioijan tulee kysyä, kuinka kauan todisteet ovat käyttökelpoisia, mitä tapahtuu, kun vain toinen puoli muuttuu, ja miten poissaolokäytäntö eroaa tahallisesta peruuttamisesta. Toipuminen julkaisijan kompromissin ja ristiriitaisten käytäntöketjujen jälkeen vaatii myös määriteltyjä tuloksia. Näiden kysymysten tulisi tuottaa dokumentoituja elinkaarisääntöjä ja valtuutettuja testejä, ei optimistisia oletuksia siitä, että vastavuoroinen julkaiseminen ratkaisee jokaisen myöhemmän tilasiirtymän.
Pidä sähköpostin todennus ja yrityksen hyväksyntä erillään
Ilmoitettu hallinnollinen suhde kahden erillisen toimialueen välillä ei muutu DMARC linjaus itsestään. RFC 9989 kohta 4.4 määrittää todennettujen tunnisteiden ja tekijän verkkotunnuksen välisen kohdistuksen. Suhdevaatimus ei muuta asiaankuulumatonta ohitusallekirjoitusta tasaiseksi, eikä tämä arvio luo vastaanottajan sääntöä, joka käsittelee DRPF:ää poikkeuksena.
Vastaavasti ei osoiteta postilaatikon sijoitteluetua, perittyä mainetta tai valtuutusta maksaa toimittajalle. Jos tuleva kuluttaja käyttää suhdetietoja, dokumentoi tarkka päätös, johon se vaikuttaa, ja säilytä viestien todentamisen ja liiketoiminnan hyväksymisen riippumattomat hallintalaitteet. Mahdollisesta tulevasta signaalista ei tulisi hiljaa tulla sallittujen listalle pääsyä tai syytä heikentää olemassa olevaa politiikkaa.
Kirjaa ylös, mitä ei ole vahvistettu
Ehdotettu suhdekartta toimitetaan analyyttisenä artefaktina, kun taas tilavaatimus pysyy avoimena. Tarkka vaatimus on: Kartoita yksi ehdotettu suhde, sen julkaisija, kuluttaja, validointi- ja peruutusmalli; vahvista projektin nykyinen tila. Käyttöönottoportti on: Tarkista nykyinen projektin ja käyttöönoton tila. Kuvaile ehdotusta esittämättä sitä hyväksyttynä IETF standardina.
Linkitetty sosiaalinen tili ja Datatracker-haku eivät olleet käytettävissä, eikä niitä yritetty uudelleen tai ohitettu. Etsintäpoissaolo ei voi todistaa, ettei myöhempää työtä ole olemassa. Nykytilan vahvistus, asiantuntijatarkastus, toteutus- ja yhteentoimivuustestit, live-esityksen tarkistus ja omistajan hyväksyntä ovat vielä tarpeen ennen vahvempaa päätelmää tai julkaisua.