Kaksi osapuolta tekevät raportointisuhteen
Raportointikohteen julkaiseminen verkkotunnuksessa DMARC käytäntö ilmaisee verkkotunnuksen omistajan pyynnön. Se ei edellytä yksipuolisesti riippumatonta kohdetta hyväksymään tuloksena olevat raportit. Ulkoisen kohteen vahvistus suojaa vastaanottajia joutumasta ei-toivotuiksi raporttikohteiksi. Vastaanottava puoli julkaisee luvan DNS kautta, kun taas raportointipuoli tarkistaa luvan ennen ulkoisen kohteen käyttöä.
RFC 9990 soveltaa varmennusmenettelyään tarvittaessa Organisaation toimialue vertailu näyttää ulkoisen kohteen koosteraportoinnille. Älä korvaa tätä sääntöä yksinkertaisella testillä, jonka mukaan Lähettäjä-osoitteen ja raporttiosoitteen merkkijonot eroavat toisistaan. Löytynyt käytäntöalue, kohdeisäntä ja organisaation toimialueen konteksti on säilytettävä, jotta vahvistuspäätös on toistettava. RFC 9990 , kohta 4
Muodosta omistajan nimi oikeassa järjestyksessä
Pura kohdeisäntä raportointi-URI:sta. Liitä eteen _raportti. _dmarc , liitä sen jälkeen verkkotunnuksen nimi, josta käytäntö haettiin, muuntaen verkkotunnuksen tarvittaessa A-tunnisteeksi. Tuloksena olevalla DNS omistajalla on muoto policy-domain._report. _dmarc.destination-host. Sitä pyydetään TXT tietueita. Jos muodostettu nimi ylittää DNS rajat, positiivista valtuutusmääritystä ei voida tehdä.
Tämä rakenne käyttää todellista toimialuetta, josta käytäntö haettiin. Älä lyhennä sitä tutulle vanhemmalle vain siksi, että tämä vanhempi näyttää organisaation brändiltä. Vastaavasti postiosoitteen paikallista osaa ei lisätä DNS omistajan nimeen. Säilytä alkuperäinen URI ja jäsennetty kohdeisäntä, jotta arvioijat voivat nähdä, kuinka muodostettu nimi seuraa syötteistä. RFC 9990 , kohta 4
Vahvista vastaus tutun merkkijonon tunnistamisen sijaan
Palautetut tietueet jäsennetään tunnistearvoluetteloina. Pakollisen v=DMARC1 -tunnisteen on näytettävä ensin, ja lopussa oleva puolipiste on valinnainen. Tietueet, jotka eivät läpäise määritettyä jäsennystestiä, hylätään. Vähintään yksi jäljellä oleva kelpoisuustietue muodostaa menettelyn mukaisen ulkoisen raportointijärjestelyn. Tyhjä vastaus, asiaankuulumaton TXT arvo tai ennätys väärällä versiolla sijoitus ei luo lupaa.
DMARC -version arvo on isot ja pienet kirjaimet erotteleva: DMARC1 on vaadittu arvo, ei pienten kirjainten likiarvo tai äskettäin keksitty protokollaversio. DNS nimien vertailusääntöjä ei pidä sekoittaa versioarvon kirjainkoon vaatimukseen. Tarkistuksen tulisi säilyttää tarkat vastaustavut ja tietueen rajat sen sijaan, että normalisoitaisiin tiedot pois ennen validointia. RFC 9990 , kohta 4; RFC 9989 , kohdat 4.7 ja 4.8
Kunnioita ohitus- ja epäonnistumiskäyttäytymistä
Valtuutustietue voi tarjota raportointikohteen ohituksen menettelyn mukaisesti. Ohittavan URI:n on käytettävä samaa kohdepalvelinta, joka purettiin alussa. Tämä rajoitus estää valtuutusvastausta ohjaamasta prosessia toisiinsa liittymättömien vastaanottajien ketjuun. Jos vahvistus sisältää ohituksen toisella isännällä, raporttigeneraattori ei saa luoda raporttia alkuperäiseen tai ohitus-URI:hen.
Jos vahvistus ei vahvista valtuutusta, ulkoinen URI on jätettävä huomiotta. Väliaikaisella DNS virheellä on oma hoitonsa: vastaanottaja voi päättää tilapäisesti epäonnistua toimituksessa, jotta varmennustesti voidaan toistaa myöhemmin. Säilytä tämä lupa muodossa MAY, älä yleisenä uudelleenyritystakuuna tai testatun toteutuksen kuvausta. Onnistunut DNS tarkistus ei vieläkään todista, että kohdepostilaatikko on olemassa, hyväksyy raportin koon tai syöttää aiotun asiakkaan kojelautaan. RFC 9990 , kohta 4
Erottele aggregaatti- ja vikaraporttipyynnöt
varten koontiraportit, menettely liittyy ruaan. Vikailmoitus on määritelty erikseen kohdassa RFC 9991. Ulkoisten vikaraporttikohteiden osalta tämä asiakirja vaatii saman ulkoisen varmennusmenettelyn, jossa ruf korvataan aina, kun rua esiintyy. Älä käsittele virheraportointia automaattisesti käyttöön otettuna vain siksi, että koontiraportit virtaavat, tai kopioi koontikohteen käsittelyä kuittamatta erillistä raporttityyppiä.
Vikailmoitukset aiheuttavat lisäongelmia tiedoille altistumisesta, koska niiden sisältö voi olla yksityiskohtaisempaa kuin kootut yhteenvedot. Oikea DNS valtuutustietue ei korvaa organisaation päätöstä siitä, mitä tietoja saa jakaa, kenelle ja mihin tarkoitukseen. Tämä käsikirjoitus ei anna lupaa pyytää, lähettää tai ladata todellisia raportteja. Kaikkien todellisten asetusten on täytettävä sovellettavat tietosuoja-, vastaanottaja- ja toimintahyväksynnät. RFC 9991 , kohdat 5 ja 7
Kuvitteellinen rakennus- ja hyväksymistaulukko
Oletetaan, että kuvitteellinen käytäntö on haettu osoitteesta blue.example.com ja se pyytää koontiraportteja osoitteeseen mailto:reports@red.example.net. Luotu valtuutuksen omistaja on blue.example.com._report._dmarc.red.example.net . hypoteettinen TXT -vastaus, jonka täydellinen arvo on v=DMARC1; täyttää kuvatun version ensimmäisen vaatimuksen. DNS kyselyä ei suoritettu, eikä tämä esimerkki väitä, että nimillä olisi julkaistu tietueita.
Työarkin tulee säilyttää käytännön haun tulos, löydetty käytäntötoimialue, alkuperäinen raportointi-URI, kohdeisäntä, organisaation ja toimialueen vertailu, muodostettu omistaja, kyselytyyppi, aikaleima, tarkat palautetut tietueet ja jäsennystulos. Lisää erillinen kenttä mille tahansa ohitukselle ja vahvista sen isäntärajoitus. Arvioijan pitäisi pystyä rekonstruoimaan nimi luottamatta palveluntarjoajan kuvakaappaukseen tai DNS editorin lyhennettyyn näyttöön.
Käytä keräämiseen toista hyväksymisosiota: tarkoitettu tili, kohdepostilaatikko, valtuutettu raporttityyppi ja putken omistaja. Nämä kentät kuvaavat suunniteltua varmennustyönkulkua, eivät valmiita käsittelytodisteita. Pidä DNS suhteen tulos erillään kuitista, jäsentämisestä, vuokraajan määrityksestä ja kojelaudan esityksestä. Lupien tarkistus voi onnistua, kun taas toinen osa keräyspolusta jää ratkaisematta.
Julkaisu ja toteutus pätee
Luettelo edellyttää tarkan valtuutushaun rakentamista lähde- ja kohdeverkkotunnuksista ja sen vastauksen tarkistamista. Tämä luonnos tarjoaa vain kuvitteellisen rakenteen. Varsinainen vastaus, alkuperäinen kyselyn transkriptio ja vastaanottavan verkkotunnuksen toteutus ovat avoinna. DNS tietuetta ei julkaistu, postilaatikkoon ei käyty eikä raporttia lähetetty.
Hanki valtuutettu todiste tarkasta tuotantosuhteesta ennen julkaisua, ja pyydä pätevää tarkistajaa vahvistamaan käytäntöjen löytämisen konteksti, version jäsentäminen ja ohituksen käsittely. Säilytä lähdepäivämäärä ja erota standardivaatimukset palveluntarjoajan tilin käyttöönotosta. Kaikki kuusi vapautusporttia pysyvät auki, mukaan lukien alkuperäiset todisteet, ihmisen tarkastelu, lähteiden soveltuvuus, tuotantoreitit, visuaalinen saavutettavuus ja omistajan vapauttaminen.
Myöhempi muutos kohde- tai käytännön selvitystoimialueeseen voi muuttaa vaaditun valtuutuksen omistajan. Käsittele sitä uudeksi laajuudeltaan vahvistavana suhteena sen sijaan, että oletetaan, että vanha positiivinen tarkistus kattaa kaikki tulevat raportointiosoitteet. Hyödyllinen tulos on tarkastettava lupaketju, ei vain kopioitu TXT -arvo.