Otsikkoanalysaattori voi olla eri mieltä alkuperäisen vastaanottimen kanssa ilman, että kumpaakaan havaintoa on tehty. He ovat saattaneet arvioida eri viestitavuja, eri DNS avaimen tilaa tai erilaisia vahvistuskäytäntöjä eri aikoina. Säilytä alkuperäiset todisteet ja vertaa olosuhteita ennen kuin päätät, mitä erimielisyys tarkoittaa.
Näytetty historiallinen tulos ja tuore kryptografinen vahvistus ovat eri toimintoja. Jotkut työkalut tiivistävät Authentication-Results on jo näytteessä. Toiset hakevat avaimet ja tarkistavat nykyisen näytteen. Selvitä, minkä toiminnon analysaattori suorittaa, ennen kuin vertaat sen ulostuloa vastaanottavan järjestelmän tulokseen.
Säilytä alkuperäinen ja tunnista raja
Vie raakaviesti käyttämällä menetelmää, joka säilyttää viestin esityksen. Säilytä muokkaamaton alkuperäinen ja laske tiedoston tiiviste myöhempää vertailua varten. Kirjaa ylös noutotapa, toimitusaika ja lähdepostilaatikko. Tiedoston hajautus voi osoittaa, että kaksi vietyä tiedostoa eroavat toisistaan; se ei itse selitä millä erolla on merkitystä DKIM.
Tunnista vastaanottimen luoma Authentication-Results ja sen luotettu todennuspalvelutunnus. Epäluotettavan lähettäjän toimittamat otsikot eivät ole todistusvoimaisia vastaanottajan todisteita. RFC 8601 §7.1 kuvaa tätä luottamuksen rajaa. Määritä myös, arvioiko vastaanottaja viestin ennen kuin myöhempi yhdyskäytävä tai vientiprosessi muutti sitä.
Vertaa analysaattorin todellisia syötteitä
Tavallisessa koko rungon allekirjoituksessa kopioidusta otsikkolohkosta jätetään pois DKIM n uudelleen laskemiseen tarvittava runko body hash. Erikoistapaus l=0 tiivistää nolla runkooktettia eikä suojaa kehon eheydeltä; se ei luovu otsikon, avaimen tai muista varmistustarkistuksista. Katso RFC 6376 §3.5, §3.7 ja §5.4.1. Tekstin liittäminen voi myös muuttaa taitto- tai rivinpäätteitä. Jos analysaattorilta puuttuu koko viesti, se saattaa tulkita raportoituja tuloksia sen sijaan, että se tarkastaisi itsenäisesti koko allekirjoituksen. Sen käyttöliittymämerkintä ei yksin ratkaise tätä kysymystä.
Vertaa täydellisiä näytteitä, kun niitä on saatavilla. DKIM kanonisointi sisään RFC 6376 §3.4 sietää määritellyt muunnokset, ei mielivaltaista renderoidun sisällön vastaavuutta. Eri tiedostotiiviste ei automaattisesti tarkoita DKIM virhettä, koska jotkin tavumuutokset saattavat normalisoitua. identtinen tiedostotiiviste muodostaa vain identtiset toimitetut tavut, ei identtistä DNS tai käytäntökontekstia.
Tarkista, mikä muuttui DNS ssä ja ajassa
Lue d ja s jokaiselle allekirjoitukselle ja kirjaa muistiin myöhemmän tarkistuksen aikana havaitut keskeiset vastaukset. Alkuperäinen avain on ehkä poistettu käytöstä, peruutettu tai vaihdettu toimituksen jälkeen. RFC 6376 §6.1.2 varmennus perustuu asianmukaisen varmennusmateriaalin hakemiseen, joten historiallinen passi voi esiintyä rinnakkain myöhemmän ei-avaimen tuloksen kanssa.
Tarkista myös allekirjoituksen vanhenemisen x-arvo ja todentajan ajankäsittely. Myöhempi työkalu voi arvioida allekirjoituksen vanhenemisen jälkeen. RFC 6376 §6.1.1 sallii todentajien jättää huomiotta vanhentuneet allekirjoitukset; tietyn työkalun käyttäytyminen on tarkistettava eikä oletettava. Älä merkitse tulosta todisteeksi siitä, että allekirjoitus oli vanhentunut, kun vastaanottaja alun perin käsitteli sen. Jos vanha DNS vastaus ei ole saatavilla, ilmoita, että historiallista kryptografista laskelmaa ei voida täysin toistaa nykyisten todisteiden perusteella.
Käy läpi kaksi vastakkaista esimerkkiä
Havainnollistava esimerkki yksi: vastaanotinraportit hyväksyvät valitsin old1 maanantaina ja lähettäjä jää eläkkeelle old1 perjantaina. Lauantain uusintatarkastus kertoo, ettei avainta ole. Tämä myöhempi tulos ei poista maanantain luotettua havaintoa, vaikka maanantain vahvistuksen toistaminen itsenäisesti vaatii asiaankuuluvat historialliset syötteet.
Havainnollistava esimerkki kaksi: alkuperäinen vastaanotettu tiedosto vahvistaa, kun taas liitetty kopio epäonnistuu alatunnisteen tai MIME serialisoinnin muutosten jälkeen. Vertaa katettua esitystä ja kohtaa, jossa muutos tapahtui. Ongelma voi olla pikemminkin näytteen käsittelyssä kuin lähettäjän alkuperäisessä allekirjoituksessa. Nämä ovat vertailukalusteita, eivät väitteitä todellisesta analysaattorista tai vuokralaisesta.
Ilmoita erimielisyydestä tarkasti
Luo vertailutietue, joka sisältää näytetiivisteet, keräysmenetelmät, havaintoajat, d ja s, keskeiset vastaukset, todentajaversiot, raportoidut tulokset ja tunnetut käytäntöerot. Tarkista useita allekirjoituksia erikseen, koska työkalut voivat korostaa eri allekirjoituksia. Pidä DKIM kelpoisuus erillään DMARC linjaus ja lopullinen toimitus.
Tee johtopäätökset vain siitä, mitä todisteet tukevat: erilaiset tavut, muuttunut DNS , kulunut voimassaoloaika, erilainen valittu allekirjoitus tai ratkaisematon konteksti. Säilytä epävarmuus, kun alkuperäiset tulot puuttuvat. Myöhempi analysaattori on hyödyllinen diagnostinen näyttö, mutta se ei ole aikakone, eikä sen pitäisi hiljaa korvata luotetun alkuperäisen vastaanottimen tulosta.
Seuraavaa päätöstä varten tarvitaan todisteita
Käytä vertailuriviä kullekin allekirjoitukselle: alkuperäinen näyte hash/aika, myöhempi näyte hash/aika, d/s, havaittu avain, x, jos olemassa, työkalu/versio, toiminta (raportin jäsennys tai vahvistus), tulos ja jäljellä oleva aukko. Identtiset näytetavut, joissa historiallinen DNS ei ole käytettävissä, jättävät avaimen tilaraon, eivät todiste siitä, että kumpikaan työkalu on väärä. Jos näytteet eroavat toisistaan, vertaa katettua kanonista esitystapaa ennen syy-seuraussuhteen määrittämistä.