Viesti, jossa on useita DKIM allekirjoitukset tarvitsevat allekirjoituskohtaisen arvioinnin. Allekirjoitusten laskeminen tai ensimmäisen ohimenevän tuloksen valitseminen voi tunnistaa virheellisesti näkyvän tekijän todenneen verkkotunnuksen. Under RFC 9989 §4.4.1, mikä tahansa ohittava DKIM-todennettu tunniste, joka vastaa tekijän verkkotunnusta, voi toimittaa DKIM polun DMARC syöttö.
Säilytä jokaisen tuloksen identiteetti
Vie raakaviesti hyväksytyn prosessin kautta. Tallenna näkyvä From-verkkotunnus ja jokaiselle allekirjoitukselle sen d= verkkotunnuksen allekirjoittaminen, s= valitsin, a= algoritmi ja asiaankuuluva kanonisointi asetukset. Yhdistä luotetun vastaanottavan järjestelmän tulos tähän allekirjoitukseen. Kaksi allekirjoitusta voi käyttää samaa verkkotunnusta, mutta eri valitsimia tai algoritmeja, joten toimialue ei välttämättä erota niitä toisistaan.
Älä luota mielivaltaiseen Authentication-Results kenttään vain siksi, että se näkyy viestissä. RFC 8601 §1.2 selittää näiden kenttien luottamusrajan. Käytä tuloksia, jotka johtuvat vastaanottavasta järjestelmästä, jonka arviota tutkit, ja säilytä tämä lähde viedessäsi todisteita. Lähettäjä voi lisätä harhaanjohtavaa otsikkotekstiä; kopioitu tilatarra ei ole itsenäinen vahvistus.
Säilytä vahvistus ja kohdistaminen erillisinä päätöksinä
Vahvistus määrittää, vahvistaako allekirjoitus sen allekirjoitusalueelle. Tasaus vertaa todennettua toimialuetta tekijän verkkotunnukseen sovellettavan DMARC säännön mukaisesti. Liittymättömän palveluntarjoajan allekirjoitus voi olla täysin kelvollinen ilman tekijän näkyvän verkkotunnuksen todentamista DMARC :lle.
Tiukkaa DKIM kohdistusta varten verkkotunnusten on vastattava täsmälleen. Seuraavassa on verkkotunnuksen kirjainkokovertailu RFC 1035 §2.3.3. Rento yhdenmukaistaminen käyttää organisaation ja toimialueen välistä suhdetta sovellettavan DMARC prosessin mukaisesti. RFC 9989 §4.10.2 määrittää DNS Tree Walks -kävelyt tätä määritystä varten. Älä päätä kohdistusta kahden verkkotunnuksen yleisen sanan perusteella, äläkä oleta hiljaa, että jokainen vastaanottaja on omaksunut uusimman etsintätoteutuksen.
Työskentele synteettisen viestin kautta
Oletetaan, että voimassa oleva DMARC käytäntö, tekijän verkkotunnus example.com eikä tasattu SPF syöttö. Allekirjoitus A käyttää d=example.net, vahvistaa onnistuneesti eikä kohdista. Allekirjoitus B käyttää d=example.com mutta todentaminen epäonnistuu myöhemmän sisällön muutoksen jälkeen. Kumpikaan ei tarjoa tasattua läpäisevää DKIM identiteettiä, joten tämä yhdistelmä ei tuota DMARC hyväksyntää.
Lisää nyt allekirjoitus C kanssa d=example.com joka vahvistaa onnistuneesti. Se kohdistuu tarkasti, joten se toimittaa DKIM polun DMARC -passiin. Liittymätön hyväksyntä ja epäonnistunut allekirjoitus eivät automaattisesti peruuta C:tä. Tämä on havainnollistava arviointi, ei väite kaapatusta asiakasviestistä tai taatusta postilaatikon sijoittelusta.
Kirjoita esimerkki erillisiin sarakkeisiin tutkimustietueessa: allekirjoituksen tunniste, varmennustulos, kohdistustulos ja panos DMARC iin . Älä koskaan yhdistä allekirjoituksen A:n hyväksyntää allekirjoituksen B kohdistettuun verkkotunnukseen tuottaaksesi tuloksen, jolla ei saavuteta yksittäistä allekirjoitusta.
Selitä, miksi allekirjoituksia on useita
Rinnakkaisalgoritmit, palveluntarjoajan operatiivinen allekirjoitus ja välittäjän myöhempi allekirjoitus voivat kaikki luoda useita tuloksia. Nämä ovat hypoteeseja, kunnes reitti- ja allekirjoittajamääritykset löytävät syyn. RFC 8463 §6 kuvaa erilliset valitsimet RSA:lle ja Ed25519 siirtymä allekirjoitukset; niiden tuloksia tulee seurata yksilöllisesti.
Jos yhdyskäytävä allekirjoittaa muokatun sähköpostin uudelleen, tarkista sen uusi toimialue. Läpivä yhdyskäytävän allekirjoitus ei automaattisesti korjaa alkuperäisen kirjoittajan todennusta. Jos organisaatio hallitsee viimeistä allekirjoitusvaihetta, varmista, että se allekirjoittaa aiotun jälkikäsittelysisällön hyväksytyllä henkilöllisyydellä. Älä poista ilmeisen ylimääräistä allekirjoitusta tarkistamatta sen käyttötarkoitusta.
Lopeta viestitason päätelmä
Kun olet arvioinut kaikki asiaankuuluvat DKIM -allekirjoitukset, arvioi SPF :n todennettu tunniste ja kohdistus erikseen. Jos soveltuvaa DMARC käytäntöä ei löydy, älä merkitse tilannetta uudelleen normaaliksi DMARC virheeksi. Erottele todennustulokset vastaanottajan lopullisesta sijoituksesta, mikä voi kuvastaa lisäkäytäntöä tai suodatusta.
Säilytä alkuperäinen viesti, luotettava tuloslähde, allekirjoituskohtainen analyysi ja syy lopulliseen johtopäätökseen. Jos raportointityökalut yhdistävät allekirjoitukset eri tavalla, vertaa niiden raakatodisteita, ennen kuin käsittelet erilaisia yhteenvetoja protokollan ristiriitaisina. Hyödyllinen tulos on selitettävissä oleva identiteettipolku, ei vain suurempi määrä vihreitä indikaattoreita.
Tallenna esimerkki sekoittamatta identiteettejä
Säilytä yllä olevassa synteettisessä viestissä yksi rivi allekirjoitusta kohti:
- V: example.net ; tarkastuspassi; kohdistus nro; DKIM avustus DMARC :lle nro.
- B: example.com ; vahvistus epäonnistui; verkkotunnus täsmää, mutta sitä ei ole todennettu; DKIM -avustus nro.
- C: example.com ; tarkastuspassi; linjaus kyllä; DKIM -panos kyllä.
Ennen kuin C on läsnä, ilmoitettu kohdistetun SPF n puuttuminen ei jätä ohitusreittiä. Kun C on käytössä, DMARC noudattaa oletettua sovellettavaa käytäntöä. Varsinaisia vastaanottajatuloksia tai postilaatikon sijoittelun tuloksia ei vaadita.
Aiheeseen liittyvää luettavaa
DKIM kohdistus: vertaa d=:ta näkyvään From-verkkotunnukseen · RSA- ja Ed25519 DKIM -allekirjoitukset: käyttöönottokysymykset ja yhteentoimivuus.