Rakenna hyväksytyistä lähettäjistä, ei arvatuista toimittajaluettelosta
An SPF rakentajan tulee säilyttää organisaation nimenomaiset päätökset siitä, mitkä järjestelmät voivat käyttää tiettyä SMTP identiteettiä. Kätevä luettelo suosituista palveluntarjoajista ei pysty varmistamaan, että kyseiset palvelut ovat valtuutettuja kyseiselle toimialueelle, että niiden suositeltu mekanismi on ajan tasalla tai että tuloksena oleva tietue vastaa hakurajoja. Tulosteen tulee olla lähettäjän omistajuuteen sidottu huomautuksilla varustettu ehdotus, ei brändin tunnistamisesta koottu laaja valtuutus.
RFC 7208 määrittelee SPF julkaisemisen ja arvioinnin. Tässä artikkelissa ehdotetaan rakentajalle ja sen tarkistusprosessille asetettuja vaatimuksia. Se ei väitä, että EmailAuth tarjoaisi mitään tiettyä rakennusominaisuutta, luo tuotantotietuetta tai muokkaa DNS . Toimittajatiliä, yksityistä kirjautumistietoa tai käyttäjän verkkotunnustietuetta ei tarkastettu. Alkuperäinen tulos ja testitodisteet ovat avoinna.
Inventoi todellinen SMTP identiteetti ja omistaja
Tallenna jokaiselle työnkululle liiketoiminnan tarkoitus, hyväksytty palvelun omistaja, lähetyspalvelu, asiaankuuluva POSTIA LÄHETTÄJÄ tai HELO identiteetti ja ehdotetun luvan lähde. SPF ei todenna suoraan näkyvää From-näyttönimeä. Yhden tiimin käyttämää palveluntarjoajaa ei pitäisi automaattisesti lisätä jokaiseen organisaation toimialue. Suunniteltu henkilöllisyys ja palvelusuhde tarvitsevat nimenomaisen vahvistuksen vastuulliselta omistajalta.
RFC 9989 määrittelee linjaus suhde, jota SPF voi edistää DMARC. Rakentajan tulee selittää, että SPF valtuutus ja DMARC kohdistus liittyvät toisiinsa, mutta erillisiä päätöksiä. Palveluntarjoajan lisääminen an SPF ennätys ei takaa, että palveluntarjoaja käyttää kyseistä identiteettiä todellisessa postissa. Integroinnin omistajan on toimitettava nykyiset kokoonpanot ja valtuutetut viestit varmistaessaan työnkulkua.
Käytä voimassa olevia palveluntarjoajan ohjeita laajentamatta soveltamisalaa
Tarkan sisällytettävän kohteen tai osoitealueen tulee olla peräisin nykyisestä virallisesta dokumentaatiosta tai todellisen palvelun valtuutetusta määrityksestä. Älä päättele sitä toisen asiakkaan tietueesta, vanhasta opetusohjelmasta tai samannimisestä tuotteesta. Merkitse todisteen päivämäärä ja palveluntarjoajan seurannasta vastuussa oleva omistaja vaihtuu. Tämä käsikirjoitus ei keksi tarjoaja sisältää arvoja, koska mitään erityistä lähettäjän määritystä ei ole hyväksytty rakentamiseen.
Suorat IP-mekanismit ja delegoidut riippuvuudet sisältävät erilaisia ylläpitovelvoitteita. Staattiset osoitteet voivat välttää saman hakuajan budjetin kuin DNS-kyselyn aiheuttavat mekanismit, mutta kopioimalla palveluntarjoajan nykyiset osoitteet ennätys voi vanhentua, kun palveluntarjoaja muuttaa infrastruktuuria. Rakentajan ei pitäisi hiljaa tasoittaa riippuvuuksia optimoinnina ilman hyväksyttyä huoltomallia. Säilytä kompromissi ja omistajan päätös huomautuksessa.
Luo yksi johdonmukainen SPF käytäntö
RFC 7208 vaatii yhden SPF tietueen arvioitua identiteettiä varten; useiden SPF tietueiden julkaiseminen ei ole kelvollinen tapa yhdistää useita palveluita. Ehdotetussa muutoksessa olisi siksi kuvattava, kuinka nykyiset valtuutetut lähettäjät säilytetään yhtenä yhtenäisenä käytäntönä. Sen ei pitäisi yksinkertaisesti ohjeistaa operaattoria lisäämään toista v=spf1 tietuetta olemassa olevan tietueen viereen. Liittymätön TXT tietueita ei saa poistaa sivuvaikutuksena.
RFC 1035 määrittää TXT tietuerakenteen. Useat merkkijonot yhdessä TXT tietueessa eroavat useista TXT -tietueista, joten rakentajan näytön ja testilaitteiden tulisi säilyttää tämä ero. Editori voi muotoilla pitkän arvon eri tavalla kuin sen lankaesitys. Hyväksytyn tarkan eron tulee määrittää aiottu tietuejoukko sen sijaan, että luottaisi yksittäisen kentän kuvakaappaukseen.
Selitä mekanismit, tarkenteet ja modifioijat
Jokaisella luodulla termillä tulee olla omistaja ja perustelut. Sisällytä edustajille arvio standardin tuloskartoituksen mukaisesti; redirect on muuntaja, jolla on eri semantiikka ja se jätetään huomiotta, jos kaikki mekanismit ovat olemassa. Rakentajan ei pitäisi vaihtaa niitä keskenään vain siksi, että molemmat viittaavat toiseen verkkotunnukseen. Tarkennukset vaikuttavat täsmäämismekanismiin liittyvään tulokseen, ja ne tulisi valita nimenomaisella käytäntöpäätöksellä.
Älä tarkoita, että kaikkien lisääminen tekee kaikista kokoonpanoista turvallisia. Sijoittelu ja tarkentaja ovat tärkeitä, ja liian laaja valtuutus voi kumota aiotun rajan. Päinvastoin, rajoittava pääte voi vaikuttaa kelvollisiin lähettäjiin, jotka jätettiin pois luettelosta. Rakentajan tulee tuoda esiin ratkaisemattomia työnkulkuja ja vaatia hyväksyntä ennen julkaisemista sen sijaan, että hän valitsee liiketoimintariskin asennon automaattisesti mallista.
Tarkista arviointirajat sekoittamatta laskua
RFC 7208 osio 4.6.4 rajoittaa arvioituja DNS-kyselyitä aiheuttavia termejä, kuten include, a, mx, ptr, olemassa ja ohjaa kymmeneen. Tämä ei ole kymmenen näkyvän palveluntarjoajan nimen tai kymmenen raakapaketin raja. Sisäkkäisillä riippuvuuksilla ja todellisella täsmäytyspolulla on merkitystä. Rakentajan tulee toimittaa riippuvuuskatsaus ja tunnistaa, mitä se ei ole arvioinut, sen sijaan, että varmennettaisiin kaikki mahdolliset syötteet matalasta laskennasta.
Standardi suosittelee myös kahden void-lookup-rajan määritettävissä olevaa toimintaa ja määrittelee lisärajat tietyille mekanismeille. Generaattorin staattinen lähtö ei määritä, kuinka kaikki vastaanottimet arvioivat jokaisen polun tulevassa DNS tilassa. Pidä polkutestit erillään muotoilutesteistä. Rakentaja voi selittää todennäköiset riippuvuudet väittämättä, että onnistunut syntaksin tarkistus todistaa yleisen SPF menestyksen.
Omistuksen säilyttävä tulostetaulukko
Luo laskentataulukko, jossa on tunnisteverkkotunnus, työnkulku, yrityksen omistaja, tekninen omistaja, hyväksytyt lähettäjän todisteet, ehdotettu termi, perustelut ja ylläpitovastuu. Lisää olemassa oleva tietueviittaus, tarkka aiottu ero, ratkaisemattomat lähettäjät, hakupolun tarkistus, vahvistussuunnitelma ja palautusehdot. Tuotoksessa tulee selittää, miksi kukin valtuutus on olemassa ja kuka voi hyväksyä sen poistamisen tai laajentamisen.
Testijoukon tulee sisältää positiivinen kelvollinen ehdotus, virheellinen syntaksi, päällekkäiset SPF tietueet ja ei-tuetut termitapaukset. Erottele tuntemattomat mekanismit tuntemattomista modifioijista, koska RFC 7208 käsittelee niitä eri tavalla. Luettelon sanamuoto vaatii ei-tuettuja tag-tapauksia; SPF tapauksessa yhdistä tämä vaatimus nimenomaisesti protokollan mekanismiin ja muokkaussanastoon sen sijaan, että keksit yleisen tunnisteen jäsentimen. Tälle luonnokselle ei tehty tällaisia testejä.
Kuvitteellinen diagnoosi: vanha toimittaja pysyy valtuutettuna
Kuvitteellinen organisaatio pyytää rakentajaa lisäämään uuden postituspalvelun. Sen nykyinen tietue viittaa myös eläkkeellä olevaan toimittajaan, mutta kukaan ei ole dokumentoinut, käyttääkö toinen työnkulku edelleen tätä riippuvuutta. Yksinkertainen rakentaja yhdistää uuden termin ja säilyttää kaiken muun ilman selitystä. Ehdotettu omistajatietoinen tarkistus sen sijaan merkitsee vanhan valtuutuksen ratkaisemattomaksi ja pyytää vastuullisia yrityksiä ja teknisiä omistajia määrittämään sen tilan.
Tiimi ei poistanut vanhaa termiä vain vähentääkseen määrää eikä lisännyt uutta toimittajaa toisiinsa liittymättömiin henkilötietoihin. Se valmistelee tarkan hyväksytyn muutoksen riippuvuuden selvittämisen jälkeen ja suunnittelee edustavan todentamisen. Tämä on kuvitteellinen elinkaariharjoitus, ei havaittu tietue, toimittajan lopettaminen tai suoritettu DNS muutos. Se havainnollistaa, miksi lähettäjän omistajuus on osa tietueen rakentamista eikä hallinnollista paperityötä jälkikäteen.
Tarkista aiottu työnkulku ennen valmistumisen ilmoittamista
Valtuutetun julkaisun jälkeen käyttötiimi säilyttää tarkat DNS havainnot ja edustajan luotettavat vastaanotetut viestit kunkin asiaankuuluvan työnkulun osalta. Näiden havaintojen tulee osoittaa todellinen identiteetti ja kohdistus, ei pelkästään sitä, että luotu merkkijono näkyy editorissa. Onnistunut näyte jää lähettäjälle, ajalle ja vastaanottajalle. se ei määritä jokaisen tulevan viestin tulosta.
Luettelo vaatii huomautuksilla varustetun tietueen ja positiivisia, virheellisiä, kaksoiskappaleita ja ei-tuettuja tunnisteita sisältäviä testitapauksia. Ne alkuperäiset esineet pysyvät avoimina. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos sisältää ehdotetun laskentataulukon ja kuvitteellisen diagnoosin, ei luotua tuotantopolitiikkaa, suoritettua testipakettia tai vahvistettua EmailAuth ominaisuusvaatimusta.