Kaksi viestiä voivat näyttää samanlaisilta sähköpostiohjelmassa ja silti tuottaa erilaisia DKIM runkotiivisteet. DKIM tarkistaa lähetetyn esityksen määrityksen jälkeen kanonisointi, ei lukijan dekoodaama näkymä. MIME uudelleenrakentaminen, sisällönsiirron muuntaminen ja rajojen muutokset kuuluvat siksi tutkimuksen alkuvaiheeseen, kun viesti epäonnistuu vasta käsittelypalvelun jälkeen.
Erillinen ulkonäkö esityksestä
MIME viesti voi sisältää pelkkää tekstiä, HTML-koodia, liitteitä ja sisäkkäisiä moniosaisia rakenteita. RFC 2046 §5.1.1 sijoittaa MIME osien otsikot ja rajaviivat moniosaisen rungon sisään. Tekstiosan uudelleenkoodaus lainaus-tulostetusta arvosta base64 voi säilyttää käyttäjän lukeman muuttaessaan DKIM lle esitettyjä tavuja. Koodattujen rivien uudelleen rivittäminen voi myös muuttaa näitä tavuja. Rento kanonisointi on määritetty välilyöntimuunnos, ei MIME dekooderi tai renderoidun sisällön vastaavuustesti.
RFC 6376 §5.3 neuvoo muuntamaan sopivaan MIME -siirtokoodaukseen ennen allekirjoittamista siirtomuunnosten vähentämiseksi. Se vaatii erityisesti, että paikalliset esitykset, jotka muuttuvat ennen lähetystä, normalisoidaan ennen allekirjoittamista. Periaate on toiminnallisesti yksinkertainen: allekirjoita lomake, jonka vastaanottajan odotetaan näkevän.
Paikanna serialisoinnin muutos
Hanki raakaviestit allekirjoittajan lähdöstä, epäillystä yhdyskäytävän lähdöstä ja lopullisesta vastaanottajasta. Tallenna alkuperäiset asiakirjat avaamatta ja tallentamatta niitä editorin kautta, joka normalisoi rivinpäätteet. Huomaa keräysmenetelmä, koska vientityökalu voi itse muuttaa esitystä.
Vertaa ulomman viestin ja kunkin asiaankuuluvan MIME osan Sisältötyyppi- ja Sisällönsiirto-koodauskenttiä. Tarkista rajamerkkijonot, liitekoodaus, taitetut rivit ja merkistömuunnos. Selvitä, sisältyikö muuttunut ulompi otsikko h:hen ja tapahtuiko muuttuneiden osien otsikoita allekirjoitetun rungon sisällä. Käsittele kahta sijaintia erikseen: ulompi otsikko voi aiheuttaa allekirjoituksen vahvistuksen epäonnistumisen, kun taas MIME osan otsikko osallistuu normaalisti body hash.
Käy läpi koodausesimerkki
Havainnollinen testispesifikaatio: tekstiosa, joka sisältää ei-ASCII-merkin, valmistetaan käyttämällä lainausmerkkiä, ennen kuin sovellus allekirjoittaa viestin. Alavirran palvelu purkaa kyseisen osan ja sarjoittaa sen base64:ksi. Näytetty lause pysyy samana, mutta kanonisoitu runko voi poiketa ja alkuperäinen allekirjoitus voi epäonnistua. Suorita tämä vain kontrolloidulla sisällöllä ja tarkista todelliset tavuerot sen sijaan, että olettaisit, että jokainen palvelu suorittaa tämän muunnoksen.
Luo pieni testisarja, joka sisältää vain ASCII-tekstiä, ei-ASCII-tekstiä, moniosaista HTML-koodia ja pienen liitteen. Lähetä jokainen suoran ohjauspolun ja tuotantoa vastaavan käsittelypolun kautta. Jos vain jälkimmäinen muuttaa esitystä, rajavertailu identifioi tutkittavan komponentin. Jos kumpikaan epäonnistuu, tutki ensin allekirjoittajan oma serialisointi ja normalisointi.
Korjaa raja
Valitse lopullinen MIME -rakenne ja siirtokoodaus ennen allekirjoittamista. Jos tietoturvapalvelun on kirjoitettava sisältöä uudelleen, järjestettävä valtuutettu allekirjoitusvaihe sen lopullisen serialisoinnin jälkeen. Vahvista sen mukautetun verkkotunnuksen tuki ja omistusmalli; Liittymättömän palvelualueen alla oleva allekirjoitus voi läpäistä DKIM ilman, että se on kohdistettu DMARC alla RFC 9989 §4.4.1.
Älä korjaa näytettä paikalleen ja esitä se todisteeksi siitä, että tuotanto on kunnossa. Muokattu näyte testaa vain hypoteesin. Muuta vastuullista kokoonpanoa, lähetä uusia ohjattuja viestejä ja tallenna niiden alkuperäiset vastaanottajan tulokset. Vältä laajoja sisällön tarkastuksen ohituksia vain allekirjoituksen säilyttämiseksi tarkistamatta turvallisuusseurauksia.
Säilytä hyödyllinen tapahtumatietue
Tallenna ensimmäinen raja, jossa serialisoitu sisältö poikkeaa, MIME kenttä tai osa, johon se vaikuttaa, allekirjoittaja ja valitsinja kunkin testiversion tulokset. Pidä testiviestit vailla asiakastietoja. Suorita sarja uudelleen yhdyskäytävän päivitysten ja liitteiden käsittelyn muutosten jälkeen. Valmis korjaus selittää miksi vanha esitys epäonnistui ja osoittaa, että äskettäin lähetetty posti selviää täysin tuetun reitin aikana.
Vertaa konkreettista koodattua esitystä
UTF-8-tavuille C3 A9, jotka edustavat é:tä, on lainaustulostettavissa oleva esitys =C3=A9; base64-esitys on w6k=. Sopivilla MIME otsikoilla molemmat dekoodaavat samat merkit, mutta koodatut merkkijonot eroavat toisistaan. RFC 2045 §6.7 ja RFC 2045 §6.8 määrittele koodaukset; RFC 6376 §3.7 vaatii tiivistyksen siirtokoodauksen jälkeen ja ennen dekoodausta varmennuksen aikana. Tämä eristetty esitysesimerkki ei ole täydellinen MIME sanoma tai suoritettu allekirjoitustesti. Jos käytetään rungon pituusrajaa, määritä, ovatko muuttuneet tavut peittoalueen sisällä, sen sijaan, että oletetaan, että jokainen osa on suojattu.