[ Standardit ja DMARCbis ]

Testaa DMARC t -semantiikkaa ilman lupaavaa vastaanottimen tukea

Rakenna kuusi odotettavissa olevaa t-politiikkayhdistelmää, erota arviointi sijoituksesta ja tunnista vielä tarvittavat vastaanottajan todisteet.

EmailAuth -tutkimusryhmä · 6 min lukuaika

[Avainkohdat]

  • Epäonnistuneet postit t=y pehmentää karanteenin arvoon none ja reject karanteeniin; mikään ei jää mihinkään.
  • Testaus koskee valittua p-, sp- tai np-käytäntöä, eikä se kirjoita todennustuloksia uudelleen.
  • Raportointi ja lopullinen vastaanottajajärjestely pysyvät erillään; varsinaisia ​​testituloksia ei ole mukana.
Tällä sivulla

Testaus muuttaa pyyntöä, ei todennustulosta

Nykyinen t-tunniste DMARC on testaustilan signaali, joka on liitetty käytäntötietueeseen. Se ei muuta todentamatonta viestiä todennetuksi, eikä se lupaa toimitusta. Sen hyödyllinen tarkoitus on pehmentää pyydettyä arviointia DMARC-epäonnistuneesta postista samalla kun se mahdollistaa asiaankuuluvan erikoiskäsittelyn. Käyttöönottosuunnitelma tarvitsee siksi kaksi riippumatonta lähtöä: odotetun politiikan tulkinnan ja vastaanottajan todellisen käyttäytymisen.

RFC 9989 kohta 4.7 määrittää t=y ja t=n, ja n oletusarvona. Testaus toimii millä tahansa arviointikäytännöllä, joka valittiin joukosta p, sp tai np. Aloita määrittämällä tämä käytäntö ja määrittämällä, epäonnistuiko DMARC . Älä käytä muutosta mielivaltaiseen p-tunnisteeseen, kun aliverkkotunnuksen ohitus todella hallitsee viestiä.

Rakenna kuuden solun odotus ennen kuin lähetät mitään

Valitun ei-käytännön osalta y ja n jättävät pyydetyn arvioinnin arvoksi ei mitään. Valitulle karanteenille y ei pyydä mitään, kun taas n säilyttää karanteenin. Valitun hylkäyksen kohdalla y pyytää karanteenia, kun taas n säilyttää hylkäämisen. None-tulos sallii silti tavallisen vastaanotinsuodatuksen; se ei ole ohje ohittaa väärinkäytön torjuntaa tai taata, että viesti saapuu postilaatikkoon.

Kuvitteellisessa testisuunnitelmassa _dmarc.trial.north.example sisältää yhden vaihtoehtoisen tietueen kerrallaan, joista jokainen alkaa v=DMARC1 ja sisältää yhden valitun p-arvon plus yhden t-arvon. Kuusi vaihtoehtoa muodostavat matriisin, eivät kuutta samanaikaista TXT politiikkatietuetta. Useat käytäntötietueet samalla ehdokasnimellä ovat erilainen etsintäongelma, ja ne mitätöisivät aiotun vertailun. Tästä artikkelista ei ole julkaistu tietueita eikä lähetetty postia.

Säilytä erillinen odotettu tulos DMARC-läpäisevälle ohjaussanomille. Testaus ei kirjoita tätä tulosta epäonnistumaan tai tee epäonnistuneeksi SPF tulos läpäisty. Todennus, linjaus, valitun arvioinnin ja lopullisen sijoituksen tulee olla eri kentät todistepaketissa. Muuten kuvakaappaus, jossa lukee "toimitettu", voi hämärtää juuri sen käyttäytymisen, joka kokeen oli tarkoitus saada aikaan.

Sisällytä erityiskäsittely luottamatta siihen

Testausmäärittely mahdollistaa asiaankuuluvan erikoiskäsittelyn, kuten välittäjän suorittaman From-field-uudelleenkirjoituksen pehmeämmän arvioinnin ohella. Siinä sanotaan, että arvioinnin alennusta sovelletaan riippumatta siitä, tapahtuuko kyseistä erityiskäsittelyä. Testaussuunnitelman on siksi noudatettava molempia ulottuvuuksia sen sijaan, että pelkistetyn politiikan ehdoksi asetetaan näkyvä uudelleenkirjoitus.

RFC 9989 Liite A.6 selittää historian: epäjohdonmukainen prosenttikäsittely johti pct:n poistamiseen, kun taas hyödylliset käytännöt noin pct=0 ilmoittivat uuden binaaritunnisteen. Tämä historia ei tee t=y liikenteen otantaprosenttia tai väitettä, että kaikki historiallinen PCt-käyttäytyminen toistetaan. The IANA rekisteri nyt luetteloi t aktiivisena ja pct historiallisena. Rekisterimerkinnät eivät voi määrittää, mitä ohjelmistoa vastaanottava organisaatio käyttää.

Välittäjä voi muuttaa tunnisteita tavoilla, jotka vaikuttavat myöhempään kohdistukseen. Säilytä esivälittäjän ja välittäjän jälkeiset viestitodisteet vain hyväksytyssä, yksityisyyttä suojaavassa testissä. Älä päättele mekanismia vain muuttuneesta näyttönimestä tai lopullisesta kansiosta. Raportin tulee tunnistaa tarkka muuttunut kenttä, hyppy, jossa se muuttui, ja todennustulos, joka näkyy alavirtaan.

Lopullinen hylkääminen vaatii vielä vastaanottajan laajempaa analyysiä

Hylättynä merkitty matriisisolu kuvaa pyydettyä arviointia, ei automaattista SMTP tulosta. RFC 9989 kohta 7.4 edellyttää, että vastaanottajat eivät hylkää vain lähettävän toimialueen hylkäyskäytäntöä. Heidän on yhdistettävä se muihin analyyseihin, ja ilman tätä lisätietoa pitää epäonnistunutta viestiä sen sijaan karanteenina. Testi, joka jättää tämän eron huomioimatta, voi virheellisesti kutsua vaatimustenmukaista vastaanotinta vialliseksi.

Samassa osiossa korostetaan edelleenlähetys- ja postituslistojen yhteentoimivuusriskejä. Verkkotunnusten julkaisun hylkäys ei saa turvautua vain SPF DMARC -passin turvaamiseksi, ja sitä on sovellettava kelvollisesti DKIM allekirjoituksia. Testaustila ei korjaa rikkinäistä allekirjoitusta tai varmista, että jokainen epäsuora reitti on turvallinen. Sisällytä suora toimitus ja hyväksytyt edustajan epäsuorat polut, kun todellinen käyttöönotto perustuu niihin, sen sijaan, että ekstrapoloisit yhdestä postilaatikosta.

Laajenna vastaanottajan vaatimus todisteisiin, jotka voit säilyttää

Julkaistu RFC on normiviittaus, ei jokaisen palveluntarjoajan julkaisuilmoitus. Vanhempi toteutus saattaa jättää huomioimatta tunnisteen, jota se ei tunnista, mikä saattaa jättää julistetun karanteenin tai hylkäämisen arvioinnin pehmentämättä. Se on arvioitava riski, ei mitattu havainto nimetystä vastaanottimesta. Dokumentoi nykyiset toimittajan lausunnot, todelliset ohjelmistoversiot, jos ne ovat saatavilla, ja erityiset havainnot, jotka tukevat kutakin yhteensopivuuspäätelmää.

Ehdotetun valtuutetun ajon tulee säilyttää DNS -käytännön tilannekuva ja ajoitus, tarkka tietueen nimi, viestitunnisteet, kohdistussyötteet, vastaanottimen vastaukset ja kaikki saatavilla olevat raportit. Tallenna paikallisten käytäntöjen ohitukset erikseen. Toista kuuden solun vertailu kontrolloiduissa olosuhteissa sen sijaan, että muutat useita lähetysmuuttujia kerralla. Sisällytä pysäytysehdot odottamattoman hylkäämisen varalta ja säilytä hyväksytty palautussuunnitelma; tämä artikla ei valtuuta näitä operatiivisia toimia.

Myös raportointi jää erilliseksi. Itse t-tunniste ei muuta raportin luontia. Aggregoidut pyynnöt käyttävät rua ja RFC 9990 raportointisäännöt; vikapalautteessa on omat ehdot ja vastaanottajan harkintansa mukaan. Puuttuva palaute ei voi todistaa testaustunnisteen huomioimatta jättämistä, eikä palaute yksinään välttämättä selitä vastaanottajan täydellistä loppusijoituksen päättelyä.

Jätä teloitusportti rehellisesti auki

Tarkka välityspalkkio on: Testaa t=y ja t=n jokaisella käytännöllä ja säilytä vastaanottimen tulokset. Tämä paketti sisältää alkuperäisen kuuden solun odotetun matriisin, joka on valmistettu ennen luonnosta, mutta ei vastaanottimen tuloksia. Näin ollen se ei täytä tätä täytäntöönpanovaatimusta. Alkuperäisten todisteiden portti pysyy näkyvästi auki sen sijaan, että se korvattaisiin standarditekstiin perustuvalla yhteensopivuusvaatimuksella.

Ennen julkaisua teknisen omistajan on hyväksyttävä valaisin, toimivan omistajan on valtuutettava kaikki todelliset testit ja arvioijan on sovitettava havainnot yhteen nykyisten spesifikaatioiden ja vastaanottimen laajuuden kanssa. Virheiden todentaminen, asiantuntijahyväksyntä, tuotantoreittien tarkastukset, visuaalinen tarkastelu ja julkaisulupa ovat edelleen vireillä. Nykyinen puolustettava johtopäätös on se, mitä nykyinen tunniste pyytää noudattavaa toteutusta tekemään, sekä tarkat todisteet, joita siihen vielä tarvitaan.

[ Takeaway ]

Oikea odotettu matriisi valmistelee yhteentoimivuustestin; se ei korvaa säilytettyjä vastaanottimen tuloksia.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

Testin insinööri

Pidä yksi ohjattu muuttuja

Kuusi vaihtoehtoa ovat erillisiä otteluita, eivät useita samanaikaisia ​​käytäntötietueita.

Seuraavat vaiheet

  1. Tallenna valittu käytäntö ja t-arvo ajoa kohti.
  2. Säilytä ohituksen ja epäonnistumisen hallintalaitteet erikseen.
  3. Tallenna todelliset havainnot päättelemättä tukea pelkästä toimituksesta.

Postitoimintojen omistaja

Valtuuta rajoitettu suoritus

Epäsuorat reitit ja odottamaton hylkääminen voivat vaikuttaa todellisiin käyttäjiin.

Seuraavat vaiheet

  1. Hyväksy testin vastaanottajat ja kaluston omistus.
  2. Aseta pysäytys- ja palautusehdot.
  3. Pidä ehdotetut toimet erillään suoritetuista testeistä.

Yhteensopivuuden arvioija

Tarkasta jokainen vastaanottajan johtopäätös

Normatiiviset tekstit eivät voi korvata toimittajakohtaista käyttöönottotietuetta.

Seuraavat vaiheet

  1. Säilytä vastaanottimen versio tai nykyinen toimittajalausunto.
  2. Erillinen arviointi paikallisesta käsittelystä.
  3. Korjaa nykyiset virheet ja hyväksy tulkinta.

[ UKK ]

Usein kysytyt kysymykset

Mitä t=n tarkoittaa, kun tunniste jätetään pois?

n on oletusarvo ja pyytää valittua arviointia DMARC-epäonnistuneet viestit. Se ei lupaa, että lopullinen vastaanottimen sijoitus vastaa käytäntömerkintää ilman muuta analyysiä.

Muuttaako t=y kohdistetun passin epäonnistumiseksi?

Ei. Se ilmaisee valitun arvioinnin testauskäsittelyn epäonnistuneiden viestien varalta. Pidä todennus, linjaus ja käytäntöjen tulkinta erillisinä lähtöinä.

Pehmentääkö t=y myös sp:tä ja np:tä?

Kyllä. Tunnisteen määritelmä kattaa valitun p-, sp- ja/tai np-arvioinnin. Tutustu sovellettavaan tietueeseen ja valittuun tunnisteeseen ennen testaustuloksen johtamista.

Onko pehmeämmän arvioinnin ehtona uudelleenkirjoittamisesta?

Ei. Määritelmä koskee yhden tason vähennystä riippumatta muusta testauksen aiheuttamasta erikoiskäsittelystä. Kirjaa kaikki uudelleenkirjoitukset erilleen arviointituloksesta.

Vastaako testaus kymmenen prosentin näytteenottoa liikenteestä?

No. t on binäärinen. RFC 9989 n liite A.6 selittää pct:n historian, ja nykyinen IANA rekisteri merkitsee pct:n historiallisiksi sen sijaan, että se määrittäisi t:n prosentteina.

Miksi hylkäysmatriisisolu ei ole automaattinen SMTP hylkäys?

RFC 9989 n kohta 7.4 edellyttää muuta vastaanottimen tietämystä ja analysointia; Vastaanottaja ei saa hylätä vain p=reject ja hänen tulee ilman muuta tietämättä käsitellä epäonnistunutta postia karanteenina. Matriisi kuvaa pyydetyn arvioinnin.

Pyydäkö lisää raportteja, jos otat käyttöön?

Ei. t-määritelmä ei muuta raportin luontia. Aggregaattiraportointi noudattaa rua- ja RFC 9990 , kun taas vikaraporteilla on omat pyyntöehdot ja vastaanottajan harkintavalta.

Onko kuuden solun vastaanottimen testi suoritettu?

Ei. Jokaisessa odotetussa solussa on tyhjä havaintokenttä. Vastaanottimen todellinen käyttäytyminen, version laajuus, epäsuoran reitin kattavuus ja hyväksynnät vaaditaan ennen yhteensopivuuden vaatimista.

[ Lähteet ]

Lähteet

  1. IANA DMARC Parameters -rekisteri
  2. RFC 9989 : DMARC -ydin
  3. RFC 9990 : DMARC -aggregaattiraportointi

[ Sanasto ]

Sanasto

t=y
Testaussignaali, joka pyytää yhden tason pehmeämpää käsittelyä valituille karanteenille tai hylkää arvioinnit epäonnistuneen postin vuoksi.
t=n
Oletustestausarvo, joka pyytää ilmoitettua valittua arviointia DMARC-epäonnistuneet viestit.
Valittu arvio
P-, sp- tai np-käytäntö, joka on johdettu ennen testaustilan käsittelyä ja lopullista vastaanottimen käsittelyä.
Erikoiskäsittely
Toimija voi soveltaa lisäkäyttäytymistä vastauksena testaukseen, kuten kentältä uudelleenkirjoittaminen.
Luonne
Vastaanottimen käsittelytulos, joka perustuu DMARC iin ja muuhun tietämykseen pelkän käytäntömerkinnän sijaan.

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