[ SPF ]

SPF permerror : erottele liialliset haut väärin muotoilluista käytännöistä

Erottele SPF syntaksi ja tietueenvalintavirheet liiallisista arviointibudjeteista ennen korjauksen ehdottamista.

EmailAuth -tutkimusryhmä · 7 min lukuaika

[Avainkohdat]

  • Permerror on tulosluokka, ei täydellinen perussyy.
  • Väärin muotoiltu politiikka ja ylitetyt budjetit tarvitsevat erilaisia ​​todisteita.
  • Korjaa aikaisin tuettu virhe ja säilytä reitin valtuutus.
Tällä sivulla

Tulosmerkintä ei ole diagnoosi

Permerror ilmaisee pysyvän virheen SPF arviointi, mutta se ei tunnista ainutlaatuista vikaa. Väärin muotoiltu valittu käytäntö, useita sovellettavia SPF tietueita, puuttuva rekursiivinen käytäntö tai ylittynyt arviointiraja voi tuottaa tämän tuloksen eri sääntöjen kautta. Tukivastaus, joka muuttaa jokaisen permerror "liian moneksi DNS hauksi", voi lähettää järjestelmänvalvojan väärään korjaukseen ja mahdollisesti vahingoittaa kelvollista lähettäjän valtuutusta.

Aloita säilyttämällä arvioinnissa käytetty identiteetti ja syötteet. Kirjaa yhteysosoite, HELO tai POSTIA LÄHETTÄJÄ konteksti, arvioitu verkkotunnus, lähettäjän argumentti ja aika. Säilytä sitten todellinen DNS vastaus ja valittu SPF käytäntö. Ilman näitä tietoja kaksi eri raporttia voivat koskea eri identiteettejä tai erilaisia ​​tilannekuvia sen sijaan, että ne olisivat eri mieltä samasta käytännöstä. RFC 7208 , kohta 2.3, 2.4 ja 8.7

Tarkista ensin tietueen valinta ja syntaksi

SPF -politiikan valinnassa on erityisiä sääntöjä. Useat valitut SPF tietueet aiheuttavat permerror ; niitä ei ole yhdistetty laajempaan politiikkaan, eikä niitä pidä pitää kätevänä tapana jakaa toimittajia. Yhden tietueen sisällä olevat TXT -merkkijonot ovat eri asia kuin useat itsenäiset tietueet. Säilytä tietueen rajat, jotta arvioija voi erottaa esityksen yksityiskohdan todellisesta valintaongelmasta.

Syntaksi vaatii myös täydellisen politiikan tarkastelun. RFC 7208 vaatii syntaksin tarkistuksen ennen mekanismin arviointia; virheellisellä mekanismilla voi siksi olla merkitystä, vaikka joku odottaisi aiemman mekanismin vastaavan. Tunnistamattomat mekanismit ja huomiotta jätetyt tunnistamattomat modifioijat eivät ole keskenään vaihdettavissa olevia luokkia. Vältä epämääräisiä ohjeita poistaaksesi kaikki tuntemattomat tunnukset. Selvitä sen kieliopillinen rooli ja standardin käsittely ennen kuin päätät, onko kyseessä virhe. RFC 7208 , kohdat 3.2, 4.5, 4.6 ja 6

Luokittele sitten arvioinnin ja budjetin epäonnistumiset

Sisällytä DNS:n aiheuttavan aikavälin kokonaisbudjetti, a, mx, ptr, olemassa ja uudelleenohjauksen määrä arvioinnin aikana. Raja on kymmenen, ja sen ylittämisen on saatava aikaan permerror . Tämä ei ole vain DNS pakettien lukumäärä, huipputason mukaan lukien tai yksittäisten toimittajien lukumäärä. Recursio jakaa budjetin, eikä välimuistiin tallenneta loogisesti arvioituja termejä.

Muut rajoitukset tarvitsevat omat tarransa. Void-vastausten PITÄISI-tason raja on kaksi, sallituilla konfiguroinneilla ja suositeltu oletusarvo kaksi, kun se on konfiguroitavissa; sovellettavan rajan ylittäminen aiheuttaa permerror . MX käsittelyssä on muita pakollisia rajoituksia. Väite, jonka mukaan "tietueessa on vain yhdeksän sisältymää" ei sulje pois näitä muita syitä, eikä suuri raakapakettien määrä sinänsä todista, että kokonaiskymmenen aikavälin raja ylittyi. RFC 7208 , kohta 4.6.4

Erottele virhetulokset valtuutustuloksista

Fail vakuuttaa, että asiakas ei ole valtuutettu arvioituun identiteettiin. Permerror tarkoittaa, että arviointi ei voinut antaa suunniteltua lupatulosta pysyvän virheen vuoksi. Temperror edustaa ohimenevää virhettä. Ei mikään on myös erillinen tulos, ja siinä on erityinen kartoitus, kun se havaitaan sisällyttämisen tai uudelleenohjauksen kautta. Näitä tarroja ei tule tiivistää yhdeksi " SPF -virhe" -alueeksi, kun selitetään korjaustoimenpiteitä.

Vastaanottaja päättää edelleen, kuinka tuloksia käsitellään oman käytäntönsä mukaisesti. Hylätty viesti ei määritä, mikä SPF vika aiheutti hylkäämisen, elleivät todisteet tue tätä linkkiä. Vastaavasti hyväksytty posti ei todista, että käytäntö oli voimassa. Pidä todennusdiagnoosi ja toimitusjärjestely erillisissä kentissä ja vältä lupaamasta, että yksi DNS korjaus korjaa kaikki toimitusongelmat. RFC 7208 , osa 5.2, 6.1 ja 8

Triage-laskentataulukko, jossa on nimenomaiset pysäytyssyyt

Käytä laskentataulukkoa, joka on jaettu valintaan, jäsentämiseen ja arviointiin. Säilytä valinnassa kyselyn nimi, vastaus, TXT tietue rajat ja valittujen SPF tietueiden määrä. Jäsentämisessä säilytä täsmällinen ketjutettu tietueteksti, jäsennysversio, loukkaava tunnus ja rikottu sääntö. Älä normalisoi virhettä ennen kuin säilytät alkuperäiset todisteet.

Tallenna arvioinnissa jokainen saavutettu mekanismi tai muuntaja, nykyinen toimialue, laajennettu kohde, kumulatiivinen termien määrä, vastausluokitus, rekursiivinen alitulos ja jatkopäätös. Pidä tyhjät kokonaismäärät ja lisärajat erillään. Merkitse ensimmäinen tuettu pysäytyssyy. Jos jäsentäjä hylkäsi käytännön ennen arviointia, älä keksi polkua, jota arvioija ei koskaan suorittanut vain osoittaakseen toisen mahdollisen ongelman.

Korjausehdotuksessa tulee nimetä se vika, johon se puuttuu, omistaja, joka vahvistaa aiotun valtuutuksen, ja reitit, joiden on vielä toimittava. Kirjaa selvittämättömät toissijaiset havainnot erikseen. Väärin muotoiltu käytäntö voi myös sisältää liiallisen riippuvuuskaavion, mutta tutkijan tulee selittää, mikä päätelmä on havaittu ja mikä jää staattiseksi huolenaiheeksi pätevää arviointia odotettaessa.

Kuvitteellinen diagnoosi: kaksi identtistä tarraa, erilaiset korjaukset

Kuvitteellisessa tapauksessa A toimialue julkaisee kaksi erillistä TXT tietuetta, jotka molemmat ovat SPF -käytäntöjä. Hyödyllinen diagnoosi on tietueen valintavirhe, ei liiallinen hakumäärä. Ehdotettu korjaus edellyttäisi suunnitellun valtuutuksen sovittamista yhteen tuettuun käytäntöön sen jälkeen, kun kaikki lailliset reitit on vahvistettu. Mielivaltaisen tietueen poistaminen voi poistaa vaaditun palvelun äänettömästi. Varsinaista DNS vastausta tai korjausta ei kerätty tässä tapauksessa.

Kuvitteellisessa tapauksessa B yksi syntaktisesti kelvollinen käytäntö seuraa sisäkkäistä reittiä, joka yrittää yhdennentoista lasketun DNS:n aiheuttavan termin ennen vastaavuutta. Hyödyllinen diagnoosi on ylitetty kokonaisbudjetti. TXT merkkijonojen yhdistäminen ei ratkaise tätä ongelmaa, koska käytäntö on jo yksi valittu tietue. Sen sijaan tarkistus vaatii tarkan riippuvuuspolun ja tuetun uudelleensuunnittelun, joka säilyttää lähettäjän kattavuuden.

Kolmannessa kuvitteellisessa raportissa sanotaan vain " permerror " eikä se sisällä tietueen tilannekuvaa tai jälkiä. Oikea lopputulos on riittämätön todiste, ei arvaus A:n ja B:n välillä. Pyydä minimaalista diagnostiikkapakettia valtuutetun kanavan kautta, jättäen yksityisviestin sisällön ja tarpeettomat osoitteet pois. Nämä skenaariot ovat käsitteellisiä vertailuja, eivät suoritettuja kalusteita, vastaanottimen tuloksia tai todisteita siitä, että nimetty toimittaja on määritetty väärin.

Hyväksymis- ja luovutuskriteerit

Korjausvaatimuksen tulee olla kapeampi kuin " SPF on kiinteä". Ilmoita, onko tietueen valinta, syntaksi, tietty arviointipolku tai tietty toimittajariippuvuus korjattu ja mitkä todisteet tukevat tätä väitettä. Varmista, että ehdotettu muutos ei valtuuta tahattomia lähettäjiä tai sulje pois laillisia lähettäjiä. Säilytä vastaanottajan lopullinen toimitustulos vaatimuksen ulkopuolella, ellei sitä erikseen noudateta.

Tässä luonnoksessa vaadittu huomautettu polku, joka näyttää jokaisen lasketun termin ja tarkan epäonnistuneen haaran, on jäljellä. Jos varsinainen ongelma on jäsentäminen tai valinta, säilytä myös nämä ensisijaiset todisteet ja hanki ihmisen arvio siitä, kuinka se täyttää artikkelin aiotun laajuuden. Älä valmista arvioitua polkua virheelle, joka pysähtyy ennen mekanismien käsittelyä.

Täällä ei suoritettu tarkistuksia, jäsentimen suorituksia, DNS muokkauksia tai viestitestejä. Alkuperäiset todisteet, ihmisen arvio, lähteen soveltuvuus, tuotantoreitit, visuaalinen saavutettavuus ja omistajan vapauttaminen ovat avoinna. Käsikirjoitus tarjoaa triage-kehyksen ja fiktiivisiä päättelyesimerkkejä, samalla kun se kieltää nimenomaisesti väitteet valmiista operatiivisesta diagnoosista.

[ Takeaway ]

Liitä tarkka viallinen haara tai jäsennystodistus ennen kuin kutsut SPF permerror korjatuksi.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

Tukiinsinööri

Triage ennen reseptin määräämistä

Pelkkä tulosmerkintä ei voi tunnistaa korjausta.

Seuraavat vaiheet

  1. Pyydä tietueen rajat ja tarkat syötteet.
  2. Erillinen syntaksi ja polkutodistus.

DNS omistaja

Säilytä valtuutus

Vian poistaminen ei saa poistaa laillisia palveluita sokeasti.

Seuraavat vaiheet

  1. Vahvista aiotun lähettäjän kattavuus.
  2. Tarkista ehdotetut muutokset ja peruuta.

Riippumaton arvioija

Tarkista syy-yhteys

Vihreä tulos yhdelle reitille ei ole universaali oikeellisuus.

Seuraavat vaiheet

  1. Tarkista ensimmäinen tuettu pysäytyssyy.
  2. Säilytä toimitustulokset erikseen todistettuna.

[ UKK ]

Usein kysytyt kysymykset

Tarkoittaako jokainen permerror liiallisia hakuja?

Ei. Valinta-, syntaksi-, rekursiivisen politiikan ja arviointirajan virheet voivat aiheuttaa permerror virheitä.

RFC 7208 : Lähettäjäkäytäntökehys

Voiko vastaanottimella yhdistää kaksi SPF tietuetta?

Ei. Useat valitut SPF tietueet aiheuttavat permerror .

RFC 7208 : Lähettäjäkäytäntökehys

Ovatko TXT -palat erillisiä SPF tietueita?

Ei välttämättä. Useat merkkijonot yhdessä TXT tietueessa eroavat useista tietueista.

RFC 7208 : Lähettäjäkäytäntökehys

Voidaanko odotetun osuman jälkeiset syntaksivirheet jättää huomiotta?

Ei. Standardi edellyttää syntaksin tarkistusta ennen arviointia.

RFC 7208 : Lähettäjäkäytäntökehys

Käsitelläänkö tuntemattomia mekanismeja ja muuntajia samalla tavalla?

Ei. Tunnistamattomat mekanismit aiheuttavat virheen, kun taas tunnistamattomat modifioijat ohitetaan määritettyjen sääntöjen mukaisesti.

RFC 7208 : Lähettäjäkäytäntökehys

Tarkoittaako permerror , että lähettäjä oli nimenomaisesti luvaton?

Ei. Epäonnistuminen on nimenomaisesti luvaton tulos; permerror on erillinen arviointivirhe.

RFC 7208 : Lähettäjäkäytäntökehys

Onko vertailutapaukset toteutettu?

Ei. Ne ovat kuvitteellisia selittäviä tapauksia, joissa ei ole alkuperäistä kyselyä tai testikopioita.

Mikä tukee täytettyä korjausvaatimusta?

Alkuperäinen virhetodiste, hyväksytty korjaus ja laajennettu tarkistus vaaditaan edelleen; mitään ei toimiteta tässä suoritettuna tuloksena.

[ Lähteet ]

Lähteet

  1. RFC 7208 : Lähettäjäkäytäntökehys

    Osat §2.3 HELO identiteetti · §2.4 MAIL FROM Identity · §3.2 Useita DNS tietueita · §3.3 Useita merkkijonoja yhdessä DNS tietueessa · §4.5 Tietueiden valitseminen · §4.6 Tietueiden arviointi · §4.6.4 DNS haun rajoitukset · §5.1 "kaikki" § 5. § 7 · "ex" · §5. §6 muokkaimen määritelmät · §6.1 uudelleenohjaus: uudelleenohjattu kysely · §8 tulosten käsittely · §8.4 epäonnistuminen · §8.7 virhe · §10 vaikutukset infrastruktuuriin

[ Sanasto ]

Sanasto

Permerror
SPF pysyvän virheen tulos, joka vaatii lisätodisteita sen syyn tunnistamiseksi.

RFC 7208 : Lähettäjäkäytäntökehys

Valinta epäonnistui
Virhe määritettäessä sovellettavaa SPF tietuetta, kuten useita valittuja käytäntöjä.

RFC 7208 : Lähettäjäkäytäntökehys

Syntaksitodisteet
Säilytetty alkuperäinen käytäntö ja tarkka kielioppivirhe, joka tukee jäsennysdiagnoosia.
Lopeta syy
Ensimmäinen tuettu ehto, joka lopettaa tutkittavan arvioinnin.

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