[ DKIM ]

Tarkista, mitä otsikoita DKIM -allekirjoitus suojaa

Lue h-tunniste, toistuvat kentät ja kanonisointi ennen kuin väität, että viestin otsikko on suojattu.

EmailAuth -tutkimusryhmä

[Avainkohdat]

  • From on allekirjoitettava, kun taas h-tunniste tunnistaa muut valitut otsikot.
  • Toistuvat nimet valitsevat fyysiset esiintymät alhaalta ylöspäin.
  • Rento kanonisointi muuttaa määritettyä muotoilua, ei kenttäarvojen merkitystä.
Tällä sivulla

A DKIM pass ei tarkoita, että jokainen näytettävä otsikko on allekirjoitettu. Jokainen allekirjoitus valitsee otsikkokentät h-tunnisteensa kautta ja käyttää määritettyä kanonisointi algoritmi. Päättääksesi, onko aihe, vastaanottajakenttä tai muu arvo suojattu, tarkista ohittavan allekirjoituksen todellinen kattavuus.

Aloita oikealla allekirjoituksella

Kirjaa kullekin d, s, h ja c DKIM-Signature otsikko. Yhdistä vastaanottajan luotettava tulos vastaavaan allekirjoitukseen sen sijaan, että käsittelet viestitason hyväksyntää todisteena niistä kaikista. Allekirjoituksessa on oltava Lähettäjä, mutta kaikki muut otsikot eivät ole pakollisia. RFC 6376 §5.4 selittää valintasäännöt ja suosittelee hyödyllistä kattavuutta.

Jos Aihetta ei ole valittu, Aiheen muutos ei sinänsä muuta allekirjoituksella suojattuja tietoja. Tämä lausunto koskee kryptografista kattavuutta, ei sitä, onko muokattu viesti hyväksyttävä. Vastaanottava palvelu voi silti soveltaa itsenäistä politiikkaa. Vastaavasti vastaanottajan allekirjoittaminen ei sido SMTP kirjekuoren vastaanottajaa: näkyvä Vastaanottaja-otsikko ja RCPT TO -osoite ovat eri tietoja; RFC 5321 §2.3.1 erottaa SMTP n kirjekuori osoitteesta viestin sisältö.

Ota huomioon toistuvat kentät

h-tunniste ei ole vain joukko yksilöllisiä nimiä. Under RFC 6376 §5.4.2, toistuvat nimet valitsevat toistuvia fyysisiä esiintymiä otsikkolohkon alaosasta ylöspäin. Jos viestissä on esimerkiksi kolme Vastaanotettu-kenttää ja h-luettelossa on Vastaanotettu kahdesti, valitaan kaksi alinta esiintymää. Lisäämällä h:hen enemmän nimen esiintymiä kuin allekirjoitettaessa voidaan havaita kyseisen kentän myöhempää lisäystä. Tätä tekniikkaa kutsutaan usein oversigningiksi.

Älä päättele, että ylin kenttä on allekirjoitettu vain siksi, että sen nimi esiintyy kerran kohdassa h. Rekonstruoi valinta todellista otsikkolohkoa vasten. Päällekkäiset kentät, joiden pitäisi tavallisesti olla yksiköitä, herättävät myös jäsennys- ja viestin kelpoisuuskysymyksiä; DKIM laskelma ei ole lupa sivuuttaa näitä huolenaiheita.

Erota arvon muutokset normalisoidusta muotoilusta

Yksinkertaisessa otsikon kanonisoinnissa valittu kenttä on esitettävä täsmälleen allekirjoitettuna. Rento otsikon kanonisointi kirjoittaa kenttien nimet pienillä kirjaimilla, avaa jatkorivit ja normalisoi määritetyt välilyönnit. Se ei pienennä kenttien arvoja pienillä kirjaimilla tai tee eri aihetekstejä vastaaviksi. Lue valittu algoritmi ennen kuin annat virheen kirjaimille tai uudelleen rivittämiselle.

Havainnollinen testispesifikaatio: yksi ohjattu allekirjoitus valitsee Lähettäjä ja Aihe. Aiheen sanojen muuttamisen odotetaan mitätöivän tämän allekirjoituksen. Toinen allekirjoitus valitsee Lähettäjä, mutta jättää aiheen pois; saman aiheen muutoksen ei tarvitse mitätöidä toista allekirjoitusta. Kontrasti selittää odotetun kattavuuden, ei kannatusta aiheen pois jättämisestä.

Paranna allekirjoittajan kattavuutta

Valitse kentät, jotka vaikuttavat vastaanottajan tulkintaan ja voivat pysyä vakaina tuetun reitin ajan. Tarkista suositukset RFC 6376 §5.4.1 ja allekirjoittajan kykyjä. Vältä vahingossa allekirjoittamasta jäljityskenttiä, joita laillinen kuljetus lisää tai muuttaa. Testaa koko reittiä kaksoiskenttien ja muotoilutapausten avulla valvotussa ympäristössä.

Dokumentoi aiottu peittoprofiili allekirjoitusmäärityksen ohella. Hyödyllinen tarkistus kertoo tarkalleen, mitkä otsikot ja esiintymät on suojattu, mitkä normalisoinnit ovat sallittuja ja mitkä kentät jäävät allekirjoituksen ulkopuolelle. Tämä on paremmin puolustettavaa kuin kuvailla DKIM :ää koko viestin sinetiksi.

Jäljitä synteettinen otsikkovalinta

Kuvittele kolme X-esimerkkikenttää fyysisessä ylhäältä alas-järjestyksessä: uusin, keskimmäinen, vanhin. Allekirjoitusluettelo h=From:X-Example:X-Example valitsee vanhimman ja sitten keskimmäisen, ei uusimman. Kun allekirjoituksessa on vain yksi X-esimerkki, X-esimerkin luettelointi kahdesti sisältää myös poissaolevan esiintymän; toisen X-esimerkin lisääminen myöhemmin muuttaa valitun syötteen ja voi mitätöidä allekirjoituksen. Tämä on valintatehtävä, ei suoritettu allekirjoitustesti tai suositus sallia normaalisti yksittäisten kenttien kaksoiskappaleet.

[ Takeaway ]

From on allekirjoitettava, kun taas h-tunniste tunnistaa muut valitut otsikot. Toistuvat nimet valitsevat fyysiset esiintymät alhaalta ylöspäin. Rento kanonisointi muuttaa määritettyä muotoilua, ei kenttäarvojen merkitystä.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Rekonstruoi kentän valinta

Toistuvat nimet vaativat fyysisen otsikon järjestyksen.

Seuraavat vaiheet

  1. Tarkista jokainen allekirjoitus erikseen.
  2. Testaa päällekkäisten otsikoiden käsittelyä.

CISO / SecOps

Tarkista tulkintariskit

Peittämättömät kentät ja jäsennyserot voivat vaikuttaa siihen, mihin käyttäjät luottavat.

Seuraavat vaiheet

  1. Record peitto poikkeukset.
  2. Pidä vastaanottimen validointi voimassa.

Perustaja / ei-tekninen

Käytä tarkkaa varmistuskieltä

Kysy, mitkä asiakkaille näkyvät kentät ovat suojattuja, sen sijaan, että hyväksyt yleisen eheysvaatimuksen.

Seuraavat vaiheet

  1. Sisällytä aihe kattavuusarvosteluihin.
  2. Erillinen toimitus eheydestä.

[ UKK ]

Usein kysytyt kysymykset

Allekirjoittaako DKIM jokaisen otsikon?

Ei. h-tunniste identifioi valitut otsikkokentät erityisellä käsittelyllä toistuvia esiintymiä varten.

RFC 6376 §3.5

Pitääkö From allekirjoittaa?

Kyllä. RFC 6376 edellyttää, että Lähettäjä-kenttä sisällytetään allekirjoituksen otsikon peittoon.

RFC 6376 §5.4

Näkyykö samalle kuin kirjekuoren vastaanottajalle?

Ei. Allekirjoitus ei sido kryptografisesti SMTP RCPT TO -osoitetta.

RFC 5321 §2.3.1 RFC 6376 §3.7

Mikä toistuva otsikko valitaan ensin?

Valinta alkaa fyysisesti viimeisestä esiintymisestä ja toimii ylöspäin toistuville nimille h:ssa.

RFC 6376 §5.4.2

Mitä on ylimerkintä?

Jos kentän nimeä esiintyy enemmän kuin tällä hetkellä on, kentän myöhempi lisäys voi mitätöidä allekirjoituksen.

RFC 6376 §5.4.2

Onko rento tila pienillä kirjaimilla Aiheteksti?

Ei. Se kenttien nimet pienillä kirjaimilla, ei kenttien arvoja, ja käyttää erityistä välilyöntien normalisointia.

RFC 6376 §3.4.2

Voiko allekirjoittamaton aihe muuttua, kun DKIM hyväksytään?

Kyllä, jos muutos ei vaikuta muihin katettuihin tietoihin. Vastaanottajan käytäntö ja viestiturvallisuus pysyvät erillään.

RFC 6376 §3.7

Pitäisikö meidän allekirjoittaa jokainen jälkiotsikko?

Ei automaattisesti. Lailliset julkisen liikenteen muutokset voivat tehdä tällaisesta kattavuudesta hauras. Noudata ohjeita ja testaa todellinen reitti.

RFC 6376 §5.4

[ Lähteet ]

Lähteet

  1. RFC 6376

    Osat §1 · §3.4 · §3.4.1 · §3.4.2 · §3.5 · §3.7 · §5.4 · §5.4.1 · §5.4.2

  2. RFC 8601

    Osat §1.2

  3. RFC 5321

    Osat §2.3.1

[ Sanasto ]

Sanasto

DKIM
DomainKeys Identified Mail tarkistaa valitun viestin sisällön allekirjoittavan toimialueen julkista avainta vastaan.

RFC 6376 §1

Kanonisointi
Määritetyt muunnokset sovellettiin otsikoihin tai runkoon ennen DKIM tiivistystä ja -tarkistusta.

RFC 6376 §3.4

Allekirjoitettu otsikkoluettelo (h)
Järjestetty DKIM -allekirjoitustunniste, jossa luetellaan valitut otsikon nimet, mukaan lukien toistot, kun useita esiintymiä on katettu.

RFC 6376 §3.5

Ylikirjoitus
Sisällytetään enemmän otsikon nimen esiintymiä h-kenttään kuin tällä hetkellä on, joten myöhempi lisäys voi mitätöidä allekirjoituksen.

RFC 6376 §5.4.2

SMTP -kuori
Kuljetustiedot, mukaan lukien lähettäjä ja vastaanottajat, erillään viestin otsikoista ja tekstistä.

RFC 5321 §2.3.1

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta