[ SPF ]

SPF -uudelleenohjaus: delegoi käytäntö ja ymmärrä, miten se eroaa sisällytyksestä

Keskitä SPF -käytäntö poistamatta vahingossa delegointia tai muuttamatta sen merkitystä.

EmailAuth -tutkimusryhmä · 4 min lukuaika

[Avainkohdat]

  • Uudelleenohjaus toimii vain varaehtojensa puitteissa, ja kaikki ovat poistaneet sen käytöstä.
  • Arviointialue muuttuu, kun taas IP-osoite ja lähettäjäsyöttö säilyvät.
  • Tarkista jokainen ulkoinen tietue sekä jaettu kohde.
Tällä sivulla

SPF uudelleenohjaus siirtää jäljellä olevan valtuutuspäätöksen toiselle käytännölle. Se on suunniteltu tilanteisiin, joissa useiden verkkotunnusten tulisi jakaa keskitetysti hallittu valtuutus ja käytäntö, usein yhden hallinto-organisaation sisällä.

Se ei ole sisällyttimen alias, eikä se -all lopuksi ole varmuuskopio. Ennen tietueiden yhdistämistä on tärkeää ymmärtää, milloin uudelleenohjaus suoritetaan. RFC 7208 kohta 6.1 määrittelee sen käyttäytymisen.

Määritä delegoinnin ehto

Kun mikään mekanismi ei täsmää, mikään aikaisempi virhe ei ole lopettanut arviointia ja uudelleenohjaus on läsnä, SPF arvioi uudelleenohjauskohteen. Yhdistävä IP ja lähettäjä pysyvät samoina, kun taas arvioitavasta toimialueesta tulee kohde. Tuloksena oleva arviointi tuottaa tuloksen, ja puuttuva SPF on tavoitetulossa permerror mieluummin kuin ei yhtään.

Jos ulkoisessa tietueessa on kaikki mekanismit, uudelleenohjaus ohitetaan. Uudelleenohjauksen sijoittaminen ennen kaikkea ei pelasta sitä. Kirjoita uudelleenohjaus loppuun selvyyden vuoksi, mutta muista, että se on ennemminkin muokkaaja kuin vasemmalta oikealle -sovitusmekanismi.

Paikallinen mekanismi voi edeltää delegointia. Esimerkiksi eksplisiittinen ip4-käyttöoikeus voi täsmätä ennen kuin jaettua käytäntöä tarkastellaan. päättää, onko tällaisia ​​poikkeuksia tarkoitettu; muuten oletettavasti keskeinen politiikka ei välttämättä ole koko valtuutustarina.

Toiminut esimerkki: kaksi verkkotunnusta, yksi hallittu käytäntö

Oletetaan kelvollinen syntaksi, yksi valittu SPF ennätys nimeä ja onnistunutta DNS -hakua kohden tässä synteettisessä järjestelmässä east.example.com ja west.example.com julkaisevat kumpikin v=spf1 redirect=policy.example.com. Jaettu kohde julkaistaan v=spf1 ip4:192.0.2.30 -all.

Kohdassa 192.0.2.30 jokainen ulkoinen käytäntö delegoi, kohde-ip4 vastaa ja tulos hyväksytään. Kohdassa 192.0.2.31 tavoite saavuttaa -all ja delegoitu tulos on epäonnistunut. Jos kohde TXT tietue katoaa, uudelleenohjausta vaativat arvioinnit tuottavat permerror .

Muuta nyt itäpolitiikka muotoon v=spf1 ip4:198.51.100.8 redirect=policy.example.com. Tämä lisäosoite kulkee paikallisesti, vaikka jaettu kohde ei valtuuttaisi sitä. Keskuspoliittisen tarkastuksen on siksi luettava kaikki delegointitietueet sen sijaan, että tarkasteltaisiin vain kohdetta.

Vertaa samaa tavoitetta sisällyttämisen alla

Jos ulkoinen politiikka sen sijaan sisältää v=spf1 include:policy.example.com ~all, lapsipassi vastaa sisällyttää. Lapsen epäonnistuminen ei tarjoa lopputulosta; käsittely jatkuu ja ulompi ~all tuottaa softfail .

Uudelleenohjaus kuljettaa tavoitekäytännön tuloksen, kun sitä kutsutaan. Sisällytä kysyy, läpäiseekö kohde ja jatkaa sitten ulkoisen käytännön mukaisesti, kun se ei läpäise. Valitse omistusmallia vastaava rakenne sen sijaan, että käännät niiden välillä mekaanisesti.

Tarkista tilannekohtaiset säännöt

Uudelleenohjaus muuttaa nykyistä arviointialuetta säilyttäen samalla lähettäjän syötteen. Makrot ja verkkotunnuksen suhteelliset mekanismit voivat siksi riippua siitä, mitä verkkotunnusta tai lähettäjäarvoa ne käyttävät. Käytäntö, joka toimii yhdellä verkkotunnuksella, ei ole automaattisesti turvallinen toiselle.

Käytä kolmannen osapuolen lähetyspalvelussa integrointimekanismia, jota sen nykyinen dokumentaatio tukee. RFC 7208 -varoitukset, jotka ohjaavat uudelleen hallinnollisten rajojen yli, eivät välttämättä toimi luotettavasti, varsinkin kun kohdepolitiikka riippuu paikallisista osista. Älä korvaa dokumentoitua sisällytystä uudelleenohjauksella vain lyhentääksesi näkyvää tietuetta.

Käytä jaettua käytäntöä turvallisesti

Inventoi kaikki riippuvat verkkotunnukset ja paikalliset poikkeukset. Määritä yksi vastuullinen omistaja jaettuun kohteeseen. Ennen kuin muutat sitä, testaa sallittu ja ei-sallittu lähettäjä jokaisessa erillisessä käytäntökontekstissa, mukaan lukien IPv6 jos sitä käytetään. Säilytä alkuperäiset delegointi- ja jaetut tietueet yhdessä.

Under RFC 7208 §4.1 ja RFC 7208 §4.6.4, uudelleenohjaus ja saavutetut sisäkkäiset termit kuluttavat SPF DNS -termibudjetin. Havaitse silmukat ja riippuvuuden kasvu arvioinnin avulla sen sijaan, että luottaisit kunkin paikallisen tietueen lyhyeen pituuteen. Muutoksen jälkeen tarkista arvovaltaiset ja rekursiiviset vastaukset ja testaa edustaja vastaanottaa postia.

Käytännön takeaway

Uudelleenohjaus on hyödyllinen keskitys, kun todella haluat jaetun käytännön. Pidä kaikki poissa delegointitietueesta, tarkasta paikalliset poikkeukset ja testaa lähetyskontekstia, joka kestää delegoinnin.

Pidä päätös toistettavana

Kohteessa east.example.com paikallinen 198.51.100.8 -poikkeus menee ohi ilman jaetun kohteen vetoamista; jaetun kohteen katkon ei siis tarvitse vaikuttaa tähän täsmälliseen polkuun. Toinen uudelleenohjausta vaativa lähde voi kohdata kohdevirheen. Tallenna ulkotietue, lähettäjän syöttö, saavutettu tavoite ja odotettu tulos yhdessä ennen keskittämisen hyväksymistä. Jaetun politiikan muutosta tai käyttökatkostestiä ei tehty.

[ Takeaway ]

Uudelleenohjaus toimii vain varaehtojensa puitteissa, ja kaikki ovat poistaneet sen käytöstä. Arviointialue muuttuu, kun taas IP-osoite ja lähettäjäsyöttö säilyvät. Tarkista jokainen ulkoinen tietue sekä jaettu kohde.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

IT / Mail Admin

Testaa sekä delegointia että poikkeuksia.

Jaettu kohde ei ole täydellinen käytäntö, jos paikalliset mekanismit sopivat ensin.

Seuraavat vaiheet

  1. Tarkista jokainen ulkoinen tietue.
  2. Testaa makroja ja lähettäjän kontekstia.
  3. Tarkista puuttuvan kohteen tapaus.

CISO / SecOps

Hallitse keskitettyä valtuutusta.

Keskittäminen yksinkertaistaa hallintoa, mutta keskittää virheiden ja kompromissien vaikutukset.

Seuraavat vaiheet

  1. Rajoita muutoksen käyttöoikeutta asianmukaisesti.
  2. Tarkista paikalliset poikkeukset.
  3. Säilytä koordinoitu palautus.

Perustaja / ei-tekninen

Tiedä jaettu muutossäde.

Yksi keskusmuokkaus voi vaikuttaa useisiin tulokriittisiin verkkotunnuksiin.

Seuraavat vaiheet

  1. Varastoista riippuvat palvelut.
  2. Määritä käytännön omistaja.
  3. Vaadi edustavia testejä ennen käyttöönottoa.

[ UKK ]

Usein kysytyt kysymykset

Milloin uudelleenohjaus arvioidaan?

Kun mikään mekanismi ei täsmää eikä aikaisempaa virhettä ole, arviointi päättyy, mikäli tietueessa ei ole kaikkia mekanismeja.

RFC 7208 §6.1

Toimiiko uudelleenohjaus -all lopuksi?

Ei. Kaikki mekanismit ohittavat uudelleenohjauksen.

RFC 7208 §6.1

Muuttaako uudelleenohjaus alkuperäistä lähettäjää?

Ei. IP-osoite ja lähettäjäargumentit säilyvät; nykyinen arviointialue muuttuu uudelleenohjauskohteeksi.

RFC 7208 §6.1

Mitä tapahtuu, jos kohteessa ei ole SPF ää?

Delegoitu arviointi palauttaa mieluummin permerror kuin ei mitään.

RFC 7208 §6.1

Miten sisällyttäminen eroaa?

Sisällytä ottelut lapsikorttiin ja muuten voi jatkaa. Uudelleenohjaus käyttää delegoitua tulosta suoritettaessa.

RFC 7208 §5.2 RFC 7208 §6.1

Voiko verkkotunnus säilyttää paikallisen poikkeuksen?

Kyllä. Edellinen vastaavuusmekanismi voi palata ennen uudelleenohjausta. Tarkista poikkeukset, jotta keskeiset politiikkavaatimukset pysyvät oikeina.

RFC 7208 §4.6.2 RFC 7208 §6.1

Voinko ohjata mihin tahansa palveluntarjoajan SPF verkkotunnukseen?

Käytä palveluntarjoajan tukemaa kokoonpanoa. Hallintojen välisillä uudelleenohjauksilla voi olla tilannekohtainen toiminta, eivätkä ne ole vaihdettavissa sisällyttämiseen.

RFC 7208 §6.1

Välttääkö lyhyt uudelleenohjaustietue hakurajoitukset?

Ei. Uudelleenohjaus ja saavutetut rekursiiviset riippuvuudet lasketaan mukaan SPF -arviointirajoihin.

RFC 7208 §4.1 RFC 7208 §4.6.4

[ Lähteet ]

Lähteet

  1. RFC 7208

    Osat §2.4 · §4.1 · §4.6.2 · §4.6.4 · §5.2 · §6.1 · §7

[ Sanasto ]

Sanasto

SPF
Valtuutuksen arviointi yhdistävälle IP-osoitteelle ja asiaankuuluvalle SMTP tunnukselle.

RFC 7208 §2.4

SPF sisältää
Rekursiivinen syöttö tekee sisällytyksestä vastaavan; sen tarkenne määrittää sitten ulkoisen tuloksen, kun taas virheet seuraavat määritettyä kartoitusta.

RFC 7208 §5.2

SPF uudelleenohjaus
Varaarviointi kohteen nykyisenä toimialueena ja muuttumattomina IP/lähettäjätuloina; mikä tahansa mekanismi poistaa uudelleenohjauksen käytöstä.

RFC 7208 §6.1

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