Vältä kaikki tai ei mitään -arviointia
Palveluntarjoajan ohjesivu saattaa silti viitata RFC 7489 kuvailee tarkasti nykyisen tilin näytön tai tuetun lähetysreitin. Päinvastoin, juuri päivätty sivu voi toistaa historiallisia protokollaohjeita. Hyödyllinen arvosteluyksikkö on yksilöllinen ohje tai väite, ei pelkästään lainauksen ikä. Tarkastajan tulee tunnistaa, mikä on edelleen voimassa, mitä nykyiset standardit ovat muuttaneet ja mikä riippuu palveluntarjoajan todellisesta toteutuksesta.
RFC 9989 tarjoaa nykyisen ytimen DMARC spesifikaatiota ja kuvaa muutoksia RFC 7489 stä . Aggregaatti- ja vikaraportointi on nyt määritelty erikseen kohdassa RFC 9990 ja RFC 9991. Käytä näitä lähteitä protokollalausekkeiden arvioimiseen, mutta älä pidä niitä todisteena siitä, että toimittaja on jo muuttanut jokaista käyttöliittymäkenttää tai ottanut käyttöön arvioijan. RFC 9989 , liite C; RFC 9990 , kohta 1; RFC 9991 , kohta 1
Säilytä tuotteen tarkka konteksti
Ennen kuin kirjoitat oppaan merkintöjä, tallenna sen URL-osoite, säilytyspäivämäärä, tuote, suunnitelma tai tilin laajuus, jos se on mainittu, alue, reitti ja asiaankuuluvat edellytykset. Toimittajabrändi voi sisältää useita postituotteita eri määrityspoluilla. Mukautetun SMTP reitin opas ei välttämättä koske oletusarvoista API-reittiä, ja yhden isännöidyn sähköpostituotteen ohjeet eivät välttämättä kata toista saman yrityksen tuotetta.
Pidä tilillä luodut arvot erillään selittävistä esimerkeistä. Oppaan näyte valitsin tai DNS kohdetta ei tule kopioida yleiseksi tuotantoarvoksi. Samoin käyttöliittymäohje voi jäädä hyödylliseksi, vaikka sitä ympäröivien standardien selitys kaipaisi päivitystä. Säilytä tämä ero, jotta lukija ei hylkää voimassa olevaa käyttöönottoedellytystä vain siksi, että johdannossa esiintyy historiallinen RFC.
Tämä käsikirjoitus ei tarkasta nimetyn palveluntarjoajan käyttötiliä tai väitä, että tietty palvelu ei ole vaatimusten mukainen. Se tarjoaa menetelmän tulevaa lähdepohjaista tarkastelua varten. Kaikki varsinaiset tuoteohjeet on verrattava luettavaan ensisijaiseen oppaaseen ja valtuutettuun tilikontekstiin, ennen kuin ne esitetään soveltuvin osin.
Luokittele jokainen ohje viranomaisen mukaan
Käytä vähintään neljää huomautusluokkaa: tuotteen työnkulku, protokollavaatimus, toimittajakohtainen kelpoisuus tai käytäntö ja selittävä suositus. Tuotteiden työnkulku vaatii nykyisen toimittajan todisteita. Protokollavaatimukset edellyttävät asianmukaista spesifikaatiota. Palveluntarjoajan kelpoisuus voi olla tiukempi tai eri laajuinen kuin protokollan minimi, eikä sitä saa yleistää jokaiselle vastaanottajalle. Suosituksissa tulee paljastaa niiden perusteet ja rajat.
Kirjoita jokaiselle riville näyttelijä ja ehto. Vastaanottajan käytäntöjen löytämiskäyttäytyminen eroaa toimialueen omistajan DNS julkaisutehtävästä. Tietyn tilikentän määritysvaatimus voi olla tarpeen kyseiselle palvelulle muuttamatta standardin tietueen syntaksia. Raportin kohteen vastaanottolupa eroaa lähettäjän pyynnöstä lähettää raportteja sinne.
Kun lause yhdistää luokkia, jaa se. Esimerkiksi ohje antaa raportointiosoite voi olla kelvollinen käyttöliittymävaihe, kun taas väite siitä, että mikä tahansa ulkoinen osoite vastaanottaa raportteja automaattisesti, on puutteellinen. Tarkistuksessa tulee säilyttää hyödyllinen vaihe ja liittää puuttuva valtuutusehto sen sijaan, että koko opas korvattaisiin yleisillä neuvoilla.
Vertaa tiettyjä muuttuneita käsitteitä
Nykyinen DMARC ydinversion arvo on DMARC1 . Tarkastuksessa ei saa keksiä DMARC2-tietuetta tai antaa ymmärtää, että RFC-viittauksen päivittäminen vaatii DNS version vaihtamisen. Nykyinen eritelmä dokumentoi myös pct:n poistamisen, kun taas säilytetyt IANA rekisterimerkit merkitsevät historiallista. Nämä tosiasiat tukevat sen väitteen oikaisemista, että pct on nykyinen perusstandardi näytteenottohallinta ilman, että todistetaan, kuinka jokainen käyttöön otettu palveluntarjoaja käsittelee sitä.
Käytännön löytäminen ja organisaation toimialueen määrittäminen tarvitsevat myös vertailua nykyiseen spesifikaatioon vanhan yksinkertaistetun algoritmin sijaan. Raportointilausunnot tulee tarkistaa RFC 9990 tai RFC 9991 mukaan. Kirjaa tarkka ero ja sen toiminnallinen merkitys; älä käytä"DMARCbis muutti kaiken” korvaamaan osatason arvioinnin. RFC 9989 , kohta 4.7, 4.10 ja liite A.6; IANA DMARC Tags -rekisteri
Annotaatiolaskentataulukko ja hyväksymisehdot
Luo laskentataulukko, joka sisältää oppaan otteen, lähteen tilannevedoksen, tuotteen laajuuden, ohjeluokan, nykyisen valtuutuksen, ehdotetun huomautuksen ja toteutustodisteet, joita tarvitaan edelleen. Määritä yksi neljästä tuloksesta: säilytetään soveltuvin osin, säilytetään laajuushuomautuksen kanssa, päivitetään, koska standardivaatimus on muuttunut, tai ratkaisematon vireillä oleva toimittajan todiste. Nämä ovat toimituksellisia tuloksia, eivät väitteitä siitä, että jokin tuotantojärjestelmä läpäisi testin.
Työarkin tulee myös yksilöidä omistaja, joka voi vahvistaa tilikohtaiset arvot ja kaikki erikseen valtuutetut testit, joita tarvitaan käyttäytymisen määrittämiseen. Jos palveluntarjoajan opas ei ole käytettävissä, merkitse lähdeaukko sen sijaan, että korvaisit yleisen asennussarjan ja kutsuisit sitä vahvistetuksi.
Hyväksyminen edellyttää, että jokainen huomautus seisoo oman todisteensa pohjalta. Arvioijan pitäisi pystyä näkemään, miksi näytön navigointivaihe säilytettiin, kun protokollan selitystä tarkistettiin. Säilytä alkuperäinen ote ja ehdotettu sanamuoto yhdessä, jotta muutos ei vahingossa aiheuta uutta sitoumusta, tuettua ominaisuutta tai yleistä toimitettavuuslupausta.
Kuvitteellinen katsaus vanhaan siteerattu asetussivu
Kuvittele kuvitteellinen palveluntarjoajasivu, jossa on kolme ohjetta: kirjoita luotu tili DKIM tietueet, lisää raportointiosoite asetusnäytön kautta ja käytä pct:tä nykyisen standardin käyttöönoton ohjauksena. Sivulla mainitaan RFC 7489 . Mitään tällaista nimettyä sivua ei tarkastettu täällä; nämä keksityt ohjeet havainnollistavat luokitusmenetelmää.
DKIM vaihe saattaa jäädä voimaan, jos nykyinen tuotedokumentaatio ja tiliarvot tukevat sitä. Raportointiosoite-vaihe saattaa jäädä voimaan käyttöliittymätoimintona, vaikka se edellyttää lisäselvitystä ulkopuolisen valtuutuksen osalta. PCt-lauseeseen tarvittaisiin nykyisten standardien huomautus, kun taas palveluntarjoajan todellinen käsittely kyseisessä kentässä jää toteutuskysymykseksi. Yksi lainaus johtaa siis kolmeen eri arviointitulokseen.
Ehdotettu seuraava toimenpide on säilyttää tuetut tuoteohjeet, korjata standardikieli ja hankkia toimittajakohtaisia todisteita ratkaisemattomasta käyttäytymisestä. Sen tarkoituksena ei ole poistaa kaikkia olemassa olevia tietueita, ohittaa asennusvaatimuksia tai julistaa palveluntarjoajaa turvattomaksi. Kuvitteellinen esimerkki osoittaa, kuinka huolellinen tarkastelu voi olla hyödyllinen ilman, että vaaditaan liikaa pääsyä tai testituloksia.
Pidä toiminnallinen ja toimituksellinen julkaisu erillään
Toimituksellinen päivitys voi parantaa opasta ennen tuotannon vahvistusta, jos sen rajat ovat näkyvissä. Älä kuvaile huomautuksilla varustettua asiakirjaa todisteeksi siitä, että käytössä oleva tili on määritetty oikein. Toisaalta onnistunutta tilitestiä ei pitäisi yleistää jokaiseen asiakassuunnitelmaan, alueeseen tai vastaanottajan toteutukseen.
Luettelo vaatii huomautuksia, jotka osoittavat, mitkä vaiheet pysyvät voimassa, mitkä muuttuivat ja mitkä riippuvat palveluntarjoajan toteutuksesta. Todellinen lähdekohtainen selitetty opas on avoinna tälle luonnokselle. Nykyistä nimetyn palveluntarjoajan käyttöönottoa, tilillä liikkumista, DNS muokkausta tai viestitestiä ei vaadita. Alkuperäisten todisteiden portti ja muut viisi vapautusporttia pysyvät auki.
Hanki varsinainen luettavissa oleva toimittajalähde ennen julkaisua ja säilytä tarkat otteet, lähdepäivämäärät ja nykyisten standardien viittaukset. Pätevän tarkistajan tulee tarkistaa, että jokainen säilytetty ohje vastaa tuotteen laajuutta ja että ratkaisematon toteutuskäyttäytyminen jää ratkaisematta. Tämä lähestymistapa tuottaa käyttökelpoisen oppaan teeskentelemättä, että vanha lainaus yksin todistaa joko oikeaksi tai epäonnistuneeksi.