Julkaiseminen p=reject on politiikan virstanpylväs, ei sen loppu DMARC toiminnot. Lähetyspalvelut muuttuvat, uusia sovelluksia ilmestyy ja vastaanottajat säilyttävät omat käsittelypäätöksensä. Aggregaattiraportointi auttaa edelleen tunnistamaan todennusregressioita, äskettäin havaitut lähteet ja erot pyydetyn käytännön ja raportoitujen käsittelyjen välillä.
Jatka raportoinnin määrittämistä ja seurantaa käytäntömuutoksen jälkeen. Soveltuvuus riippuu edelleen verkkotunnuksen käytöstä: RFC 9989 §7.4 varoittaa hylkäämästä verkkotunnuksia, joiden käyttäjät voivat lähettää viestejä Internetin postituslistoille, ja vaatii hylättyjä verkkotunnuksia käyttämään kelvollisia DKIM eikä vain luottaa siihen SPF. Todisteet ovat edelleen osallistuvien vastaanottajien ja heidän havaintojensa rajoittamia. Hylkäämiskäytäntö ei ole todiste siitä, että jokainen toisena henkilönä esiintymisyritys on estetty tai että jokainen laillinen viesti on toimitettu.
Lue käytäntö, arviointi ja sijoitus erikseen
Viitteet: RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
Julkaistu käytäntö ilmaisee verkkotunnuksen omistajan pyytämän käsittelyn sellaisille posteille, jotka epäonnistuvat DMARC . Arviointi kysyy, onko todennettu SPF tai DKIM -tunniste linjassa tekijän verkkotunnuksen kanssa. Raportoitu sijainti kuvaa vastaanottimen raportoitua DMARC:iin liittyvää hoitoa sekä ohitustiedot, jos ne on toimitettu.
Näitä kenttiä ei pidä tiivistää yhdeksi tilaan. Ennätys p=reject yhdessä disposition none kanssa ei ole automaattisesti väärin muotoiltu: viesti on saattanut mennä läpi tai vastaanottajan käsittely on voinut poiketa pyydetystä toimenpiteestä. Tutki yhdenmukaisia tuloksia ja käytettävissä olevaa syytä sen sijaan, että arvailet pelkän käytännön perusteella. RFC 9989 säilyttää vastaanottimen harkintavallan ja RFC 9990 määrittää aggregaattikentät.
Tarkkaile laillisen reitin regressioita
Viitteet: RFC 9989 §5.3.5.
Pidä yllä olevaa luetteloa sovelluksista ja omistajista. Vertaa nykyisiä havaintoja niiden odotettuihin identiteeteihin ja tutki muuttunutta valitsin, paluupolku tai tekijän verkkotunnus ennen kuin käyttäjät ilmoittavat kadonneesta postista. Sisällytä vähäliikenteisiä ja kausittaisia reittejä, jotka voivat pysyä näkymättöminä pitkiä aikoja.
Esimerkkitapaus: aiemmin vahvistettu laskutussovellus siirtyy uudelle alustalle ja menettää kohdistettujen DKIM -allekirjoitus. SPF kulkee edelleen riippumattoman palvelualueen alaisena. Oletetaan, että voimassa oleva käytäntö ja tarkastukset on suoritettu. Ilman toista tasattua kulkupolkua viesti epäonnistuu DMARC ssa tässä synteettisessä esimerkissä. Hyödyllinen vastaus on korjata tuettu lähettäjän identiteetti, ei olettaa, että pakottaminen on tehnyt tulevasta käyttöönoton tarpeettomaksi.
Tulkitse jatkuvat luvattomat viat
Luvattomat lähettäjät voivat jatkaa lähettäjän verkkotunnuksen käyttöä täytäntöönpanon jälkeenkin. Raportit voivat näyttää havaitut epäonnistuneet todennus ja vastaanottimen käsittely kyseiselle liikenteelle. Jatkuva vikamäärä ei yksin todista täytäntöönpanon tehottomuutta; valvonta saattaa hylätä edelleen saapuvan liikenteen.
Sitä vastoin älä laske jokaista epäonnistumista vahvistetuksi estetyksi hyökkäykseksi. Attribuutio, tarkoitus, vastaanottajan kattavuus ja todellinen käsittely tarvitsevat todisteita. Raporttimäärä on havaintojen määrä, eikä raportoitu sijoitus ei ole täydellinen jatkotoimituksen tarkastus.
Yhdistä poikkeukset ja puuttuva kattavuus
Viitteet: RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
Tarkista tietueet, joissa epäonnistunut posti on käsitelty eri tavalla kuin pyydetty käytäntö. Tutki toimitetut ohitussyyt ja asiaankuuluva edelleenlähetys- tai välittäjäkäyttäytyminen. Älä oleta, että jokainen vastaanotin noudattaa samaa paikallista käytäntöä tai että jokaisella poikkeuksella on riittävä selitys kokonaisraportti.
Tarkista itse raportointiputki: kohteen omistajuus, ulkoinen valtuutus tarvittaessa, tiedonkeruuvirheet ja muutokset osallistuvissa vastaanottajissa. Hiljainen kojelauta täytäntöönpanon jälkeen voi viitata perintäongelmaan. Tee kontrolloitu testi kriittisille reiteille ja vertaa vastaanottimen todisteita sovelluslokeihin tutkiessasi toimitusta.
Säilytä täytäntöönpanon jälkeinen toimintarytmi
Määritä vastuu uuden lähettäjän käyttöönotosta, säännöllisestä inventaarion tarkistuksesta, DNS muutoksista ja raporteista. Käytä hyväksymis- ja vanhenemisprosessia väliaikaiseen käytäntöjen lieventämiseen. Varmista, että ehdotettu muutos korjaa tuetun syyn eikä vaikuta tarpeettomasti läheisiin lähettäjiin.
Sulje jokainen tarkastelu testatuilla laillisilla reiteillä, tutkituilla tuntemattomilla lähteillä, tutkituilla vastaanottimien poikkeamilla ja raportoinnissa on edelleen aukkoja. Tavoite p=reject jälkeen säilyy, selitettävissä oleva todennuskattavuus. Pelkkä politiikka ei takaa tätä varmuutta.
Sitoudu johtopäätökseen ja seuraavaan toimintaan
Säilytä fiktiivisen alustan siirtoa varten raaka SPF -passi asiaankuulumattoman palveluidentiteetin alla erillään puuttuvasta kohdistetusta DKIM stä. Myöhemmin tuettu allekirjoituksen korjaus on testattava kyseisellä reitillä. Ilmoitettu ei-käsittely jää todisteiden käsittelyyn, ei todisteeksi siitä, että todennus on palautunut tai että viesti on saapunut postilaatikkoon.