Määrittele ensin kysymys ja vastaanottaja
Myyjä saattaa tarvita todisteita allekirjoitusongelman diagnosoimiseksi linjaus epäsuhta tai raportointiero. Se harvoin tarvitsee jokaista raporttia organisaation jokaisesta toimialueesta. Aloita mainitsemalla tarkka kysymys, kyseessä oleva tuote ja tili, aiottu vastaanottaja ja mikä päätös todisteiden pitäisi mahdollistaa. Tämä estää pyynnön " DMARC tiedot” muuttumasta tarpeettoman laajaksi paljastukseksi.
Varmista, että vastaanottaja on kyseisen palvelun valtuutettu tuki- tai tekninen yhteyshenkilö. Tuttu näyttönimi tai välitetty pyyntö ei riitä varmistamaan, että jokainen liite tulee lähettää sinne. Paketin laatiminen on erillään sen lähetysluvasta. Tässä artikkelissa kuvataan vain valmistelu, eikä se valtuuta sähköpostiin, lataamiseen tai ulkoiseen jakamiseen.
Pidä kaukosäädin sidottuna reittiin ja väliin. Omaa vastaanottotyönkulkuaan tutkivan toimittajan ei pitäisi vastaanottaa asiaankuulumattomia työntekijöiden postia, markkinointia tai muuta toimittajaliikennettä vain siksi, että kyseiset havainnot kattavat saman aggregaattitiedoston.
Ymmärrä, mitä raportti voi paljastaa
Aggregaattiraportit sisältää teknisiä havaintoja ja käytäntötietoja, jotka voivat paljastaa lähettäjän infrastruktuurin ja liikenteen näkökohtia. RFC 9990 käsittelee vastaanottajien ja raporttitietojen tietosuojanäkökohtia. Vaikka kenttä ei ole viestin runko, se voi silti olla tarpeeton toimittajan tehtävän kannalta. Käsittele minimointia kenttäkohtaisena päätöksenä sen sijaan, että olettaisi, että kaikki aggregoitu tieto on vaaratonta.
Vikailmoitukset alla on erillinen ja mahdollisesti yksityiskohtaisempi valotuspinta RFC 9991. Älä niputa niitä koottujen yhteenvetojen kanssa "raporttien" yleisen hyväksynnän alle. Tunnista raportin tyyppi, sisältö ja vastaanottajan tarkoitus. Jos diagnostiseen kysymykseen voidaan vastata pienemmällä yhteenvedolla tai muokatulla otteella, valitse se täydellisen raaka-artefaktin sijaan. RFC 9990 , osa 7.1 ja 7.2; RFC 9991 , osa 7.1 ja 7.2
Rakenna tietokenttäkartta ennen muokkausta
Kenttäkartassa tulee luetella jokainen ehdokaskohde, miksi sitä tarvitaan, onko tarkka arvo tarpeen, ehdotettu hoito ja sen poistamisen seuraukset. Mahdollisia kohteita ovat vastaava Lähettäjä-verkkotunnus, allekirjoitusverkkotunnus, valitsin, kirjekuoren verkkotunnus, lähdeosoite, raporttiväli, laskenta ja arviointitulos. Niiden välttämättömyys riippuu kysymyksestä; ei ole olemassa yleistä nippua, joka pitäisi aina lähettää.
Joitakin tarkkoja teknisiä tunnisteita voidaan tarvita kohdistuksen diagnosoimiseksi tai tilikohtaisen kokoonpanon paikantamiseksi. Jos näitä arvoja ei voida jakaa hyväksytyssä laajuudessa, selitä diagnostinen rajoitus sen sijaan, että korvaat ne harhaanjohtavilla arvoilla. Muut tunnisteet voidaan poistaa tai muuttaa jatkuvasti pseudonyymisiksi suhteita säilyttäen. Säilytä yksityinen kartoitus vain tarvittaessa ja valtuutettuna, äläkä sisällytä sitä oletuksena toimittajapakettiin.
Poista asiaankuulumattomat rivit ja verkkotunnukset, tarpeettomat vastaanottajien osoitteet, viestien sisältö, sisäiset muistiinpanot ja salaisuudet. Älä koskaan sisällytä salasanoja, API-avaimia, istuntotunnuksia tai valtuustietoja tukiartefakttiin. Tarkastele tiedostonimiä, metatietoja, kuvakaappauksia ja piilotettuja laskentataulukoiden sisältöä sekä näkyvää tekstiä; muokattu kappale ei takaa, että liite on minimoitu.
Säilytä diagnostiset suhteet
Hyödyllisen todistenäytteen tulisi säilyttää ero raa'iden todennustulosten ja kohdistuksen välillä. Jos kysymys koskee sitä, miksi DMARC epäonnistui, jokaisen toimialueen korvaaminen samalla paikkamerkillä voi poistaa suhteen, joka toimittajan on ymmärrettävä. Säilytä, ovatko identiteetit samanlaisia, sukua vai erilaisia, ja merkitse selkeästi synteettiset korvaukset, jotta niitä ei erehtyä erehtyisi etsimään oikeita DNS nimiä.
Pidä raportointiväli, asiaankuuluvat tuloskentät ja laajuustiedot yhdessä. Jos vain valitut rivit jaetaan, ilmoita, että näyte on suodatettu, ja määritä valintasääntö. Älä muuta tulosta, jotta esimerkki näyttää yksinkertaisemmalta, äläkä anna ymmärtää, että suodatettu määrä edustaa organisaation kokonaisliikennettä. Anna tarvittaessa lyhyt analyytikon selitys säilytettyjen kenttien rinnalle. RFC 9989 , kohta 4.4; RFC 9990 , kohta 3.1
Hyväksymis- ja säilytystaulukko
Valmistele hyväksyntietue vastaanottajalla, organisaatiolla, tuotteella, tarkoituksella, tarkalla tiedostolla tai kentällä, vaikutusalueellaan tai reitillä, aikavälillä, herkkyydellä, siirtomenetelmällä ja säilytyspäätöksellä. Selvitä, saako myyjä säilyttää materiaalin vain tapausta varten, käyttää sitä muuhun tarkoitukseen vai jakaa sen eteenpäin. Älä oleta, että yleinen tukisuhde sallii asiaankuulumattoman uudelleenkäytön tai laajan pääsyn.
Säilytyspäätöksen tulee koskea sekä toimittajan kopiota että organisaation työkopiota. Kirjaa aiottu kesto tai poiston liipaisin ja kuka voi tarkistaa loppuunsaattamisen, jos sillä on merkitystä. Tämä on ehdotettu hallintoprosessi, ei väite, että toimittajasopimus sisältää jo erityisiä ehtoja. Jos käytettävissä olevat ehdot tai vastaanottajan käyttöoikeudet ovat epäselviä, ratkaise se ennen lähettämistä.
Hyväksyminen edellyttää, että arvioija vertaa lopullista pakettia hyväksyttyyn kenttäkarttaan. Varsinainen liite, ei pelkkä kuvaus, tulee tarkistaa toisiinsa liittymättömien rivien, piilotettujen tietojen ja tahattomien salaisuuksien varalta. Muuttuneen vastaanottajan, laajennetun tietojoukon tai uuden tarkoituksen tulisi käynnistää uusi tarkistus sen sijaan, että sitä pidettäisiin saman osuuden vaarattomana jatkona.
Kuvitteellinen tukipaketti yhdelle allekirjoitusreitille
Kuvittele kuvitteellinen kuittitoimittaja, joka tutkii kohdistettua DKIM epäonnistuminen. Organisaation raaka-aggregaattiraportti sisältää myös työntekijöiden posti- ja kampanjahavaintoja. Tässä esimerkissä ei käytetty todellista raporttia tai toimittajapyyntöä. Ehdotettu paketti sisältää vain asiaankuuluvat kuitti-reittirivit, rajatun raportointivälin, asiaankuuluvat identiteettisuhteet ja lyhyen selvityksen epävarmasta.
Työntekijä- ja kampanjarivit jätetään pois, koska ne eivät vastaa toimittajan kysymykseen. Jos toimittaja tarvitsee tarkan allekirjoitusalueen tai valitsimen, organisaation on hyväksyttävä kyseiset arvot kyseiselle vastaanottajalle ja tarkoitukselle. Muokattu näyte, joka peittää ne, voi silti olla hyödyllinen käsitteellisessä keskustelussa, mutta sitä ei voida esittää riittävänä reaaliaikaiseen DNS diagnoosiin.
Lopulliseen hyväksyntään kirjataan myös tapauskohtainen säilyttämispäätös. Pakettia ei lähetetä vain siksi, että luonnos on valmis. Jos toimittaja myöhemmin pyytää täydellisiä viestinäytteitä, kyseessä on uusi sisältöpyyntö, jolla on erilainen tietosuojaprofiili, varsinkin jos se esittelee vastaanottajia tai viestien runkoja. Seuraava vaihe on laajennettu tarkistus, ei automaattinen laajennus.
Todisteet ja vapautuksen tila
Luettelo vaatii tietokenttäkartan ja hyväksytyn vähimmäistodisteen näytteen, jossa on selkeä säilytyspäätös. Tämä artikkeli sisältää vain valmistusmenetelmän ja kuvitteellisen pakkaussuunnittelun. Varsinaista näytettä ei ole hyväksytty, vastaanottajaa ei ole selvitetty eikä lähetystä tai toimittajan poistoa ole vahvistettu.
Kaikki kuusi vapautusporttia pysyvät auki. Pätevän arvioijan tulee tarkistaa, että ehdotettu minimointi säilyttää diagnostisen kysymyksen vastaanottajan ja tarkoituksen rajoja noudattaen. Hanki tarvittava valtuutus todellisille tiedoille ja määränpäälle ennen todellista jakamista. Turvallisesti laadittu luonnos on arvokasta edistystä, mutta se ei ole todiste siitä, että myyjä olisi saanut tai käsitellyt mitään.