Under RFC 9989 §5.4, viesti voi epäonnistua DMARC ja silti hyväksytään. Toinen voi läpäistä DMARC ja tulla hylätyksi. Nämä havainnot eivät riitä päättelemään, että vastaanottaja ei huomioinut todennusta tai että toimialueen DNS tietue on rikki.
DMARC antaa vastaanottajalle verkkotunnuksen todennustodistuksen ja verkkotunnuksen omistajakäytännön harkittavaksi. Vastaanottaja hallitsee myös omaa postinkäsittelyään. Tutkimuksen on erotettava nämä tasot, ennen kuin se ehdottaa korjausta.
Käytä kolmea saraketta yhden tilan sijaan
Tallenna julkaistu käytäntö, viestin DMARC tarkistustulos ja todellinen vastaanottajan toiminta erikseen. Jokainen vastaa eri kysymykseen.
- Taso: Omistajapolitiikka; Kysymys, johon se vastaa: Mitä arviointia soveltuva verkkotunnustietue pyysi?; Hyödyllinen näyttö: Tarkka käytäntötietue ja etsintäpolku asiaankuuluvalla hetkellä
- Layer: Validation; Kysymys, johon se vastaa: Oliko ohittava todennettu identiteetti linjassa From?; Hyödyllisiä todisteita: Vastaanottimen todennustulokset ja asiaankuuluvat identiteetit
- Kerros: Käsittely; Kysymys, johon se vastaa: Mitä tämä vastaanottaja teki tällä viestillä?; Hyödyllisiä todisteita: SMTP vastaus, toimitustodistus tai vastaanottajan lokit
Ei politiikka ei tarkoita sitä SPF, DKIM ja muu suodatus on kytketty pois päältä. Passi ei pakota postilaatikon sijoittamista. Hylkäämiskäytäntö ei poista vastaanottajan analyysiä laillisista epäsuorista reiteistä tai muusta asiaankuuluvasta todisteesta.
Lähettäjä voi esimerkiksi korjata DKIM oikein ja silti vastaanottaa erillisen vastaanottajasäännön aiheuttaman hylkäämisen. Toistuva DMARC DNS muuttaminen kyseisessä tilanteessa aiheuttaa muutosriskin korjaamatta palautettua syytä.
Työskentele hyväksytyn epäonnistumisen läpi
Harkitse synteettistä viestiä, jossa on From notices@accounts.example . Sen sovellettavat käytäntöpyynnöt hylätään, mutta lopullinen vastaanotin tallentaa DMARC virheen epäsuoran reitin jälkeen. Viesti hyväksytään vastaanottajan paikallisessa käsittelyssä.
Ensimmäinen tutkimus on, oliko viesti laillinen epäsuora toimitus, kokoonpanovirhe vai luvaton käyttö. Säilytä yhteyslähde, SPF identiteetti, DKIM verkkotunnukset ja -tulokset, asiaankuuluva edelleenlähetys- tai luettelokäyttäytyminen ja kaikki käytettävissä olevat käytännön ohitussyyt.
RFC 9989 RFC 9989 §7.4 käsittelee vastaanottimen analyysiä hylkäämisen lisäksi, mukaan lukien epäsuoran postin yhteentoimivuus. Hyväksyminen ei siis ole todiste onnistuneesta DMARC vahvistuksesta. Samoin se, että vastaanottaja hyväksyi viestin, ei todista viestin olevan hyvänlaatuinen.
Ohjauksen omistajan tulee selvittää laillinen reitti, jos sellainen on olemassa, dokumentoida vastaanottajakohtaiset havainnot ja välttää väittämistä, että käytäntö takaa saman toiminnan kaikkialla. Kokonaisraportin esittely auttaa pitämään todennus- ja luovutuskentät erillisinä.
Työskentele hylätyn passin läpi
Harkitse nyt erilaista synteettistä viestiä. Sen linjassa DKIM -allekirjoitus läpäisee ja vastaanotin tallentaa DMARC hyväksynnän, mutta SMTP vastaus tunnistaa toisen käytännön tai väärinkäyttöongelman.
DMARC on vastannut onnistuneesti verkkotunnuksen todennuskysymykseen. Seuraava tehtävä on tutkia varsinainen hylkääminen, mukaan lukien täydellinen vastausteksti ja lähettäjän asiaankuuluvat palvelutodisteet. Sisältö, vastaanottaja, maine tai muu paikallinen sääntö voi vaikuttaa käsittelyyn muuttamatta DMARC tulosta.
Älä lisää asiaankuulumatonta lähetysinfrastruktuuria SPF ään vain siksi, että jokainen näytettävä mekanismi muuttuu vihreäksi. Selvitä ensin, minkä identiteetin ja reitin vastaanotin arvioi ja mikä syy esti toimituksen. Laaja luvanmuutos voi aiheuttaa uuden ongelman jättäen hylkäämisen ennalleen.
Käsittele puuttuvia ja virheellisiä tuloksia huolellisesti
Kaikki viestit eivät anna tavallista hyväksyntää tai epäonnistumista. Puuttuva soveltuva tietue eroaa olemassa olevan tietueen todennuksen epäonnistumisesta. DNS saatavuusongelma eroaa pysyvästi väärin muotoillusta käytännöstä.
RFC 9989 RFC 9989 §9.2 erottaa nämä tulosehdot. Under RFC 9989 §5.3.6, jos DNS virheet estävät vaaditun DMARC tarkistuksen, normaalia hyväksyntää tai epäonnistumista ei voida määrittää ja käsittely jää vastaanottajan muihin päätöksiin. Tallenna virhe ja siihen liittyvä kysely sen sijaan, että käsittelet sitä todisteena siitä, että lähettäjä on haitallinen.
Väliaikainen hylkääminen voi kutsua uuden toimitusyrityksen; myöhempi yritys saattaa nähdä toisen DNS tilan. Siksi tämän päivän ennätyksen kuvakaappaus on heikko todiste eilen käsitellystä viestistä.
Pyydä todisteita, jotka voivat ratkaista eron
Kerää jokaisesta kiistanalaisesta viestistä pieni tapaustietue:
- Viestien ja lähetysyritysten tunnisteet, joissa arkaluontoiset tiedot on poistettu asianmukaisesti lajittelua varten. Pidä muokkaamaton alkuperäinen erikseen hallinnassa, jos DKIM -uudelleenvahvistus tarvitaan, koska allekirjoitetun sisällön muuttaminen voi vaikuttaa vahvistukseen kohdassa RFC 6376 §3.7.
- Aikaleima ja vastaanotin, mukaan lukien täydellinen SMTP vastaus, jos saatavilla.
- Näkyy verkkotunnuksesta, SPF-arvioitu verkkotunnus ja jokainen asiaankuuluva DKIM allekirjoitusverkkotunnus.
- Luotetut vastaanottajan todennustulokset, joissa viesti on toimitettu tai lokit ovat saatavilla.
- Kyseiseen käsittelyikkunaan liittyvät sovellettavat käytäntö- ja DNS vastaukset.
- Tunnettu epäsuora reitti ja mahdollinen ohitus tai paikallisen säännön selitys.
Hylätty tapahtuma ei välttämättä toimita viestien otsikot lainkaan. Käytä lähettäjän yrityslokeja, vastausta ja vastaanottajan apua sen sijaan, että vaatisit otsikkonäytettä, jota ei voi olla kyseiselle yritykselle. Under RFC 8601 §7.1, vältä käsittelemästä ennen vastaanottorajaa lisättyjä epäluotettavia otsikoita vastaanottajan omana päätelmänä.
Sulje kotelo pienimmällä tuetulla muutoksella
Ratkaisu voi olla lähettäjän identiteetin korjaaminen, DNS virheen korjaaminen, raporttien kerääjän korjaaminen tai vastaanottajakohtaisen ongelman korjaaminen. Se voi myös olla dokumentoitu yhteentoimivuuspäätös tietylle lailliselle reitille.
Testaa vaikuttanut virtaus uudelleen muutoksen jälkeen ja säilytä uudet todisteet. Jos tulos eroaa edelleen vastaanottimien välillä, kirjaa ylös, mitä kukin tosiasiallisesti havaitsi ja mikä toteutus tai paikallisen politiikan ero jää vahvistamatta. Älä yleistä yhden vastaanottajan vastauksesta koko ekosysteemiin.
Hyödyllinen selitys yksilöi omistajapolitiikan, validointituloksen ja käsittelypäätöksen erikseen ja viittaa sitten toisiinsa yhdistäviin todisteisiin. Se riittää muuttamaan näennäisen ristiriidan tutkimukseksi omistajan kanssa ja seuraavaksi toimenpiteeksi.
Kirjaa päätös, joka voidaan tarkistaa
Hyväksytty-epäonnistunut tapaus, kirjoita p=reject, dmarc=fail ja hyväksytään erillisinä havaintoja. Hylätty-hyväksytty tapauksessa säilytä dmarc=pass ja todellinen palautettu hylkäyssyy; älä valmista DMARC korjausta. RFC 9990 §3.1.1 ja RFC 9990 §3.1.6 myös erilliset kootut arviointi-, sijoitus- ja ohitustiedot. Molemmat tapaukset ovat hypoteettisia, ei kaapattuja vastaanottimen lokeja.