Soveltamisala: Afrihost jaettu hosting ja cPanel
Afrihost julkaisee erilliset ohjeet todennustietueiden hankkimiseen cPanelissa ja niiden lisäämiseen ClientZonen jaetun hosting-palvelun DNS editorin kautta. Tämä opas seuraa tätä dokumentoitua reittiä. Se ei tarkoita, että Afrihost Pure Mail, ulkoinen postilaatikon tarjoaja, tai jokainen isännöintipaketti käyttää identtisiä tietueita tai allekirjoitusohjaimia. Luo todellinen sähköpostituote ja arvovaltainen DNS palvelu ennen muutoksen valmistelua. Tilikohtaiset arvot ja nykyinen käyttöliittymän soveltuvuus jäävät vahvistamatta.
Palveluntarjoajan SPF sukupolviohjeet käyttävät cPanelin sähköpostin toimitusaluetta: valitse verkkotunnuksen vierestä Hallinnoi, etsi SPF ja kopioi sen arvo. Sen DKIM ohjeissa käytetään samaa aluetta ja Asenna ehdotettu tietue -toimintoa. Nämä ovat ehdotettuja operaattorivaiheita, eivät tälle käsikirjoitukselle suoritettuja toimia. Afrihost SPF -sukupolvi Afrihost DKIM -sukupolvi
Erillinen luominen, julkaisu ja allekirjoittaminen
Ehdotettu tietue on todiste siitä, mitä tietty konfigurointiliittymä suosittelee. Se ei ole todiste siitä, että julkinen valtuutettu vyöhyke sisältää kyseisen arvon tai että viesti on allekirjoitettu ja varmistettu onnistuneesti. Säilytä verkkotunnuksen konteksti ehdotetun tietueen rinnalla. Järjestelmänvalvoja, joka kopioi arvon väärältä isännöintitililtä, voi tuottaa uskottavan näköisen mutta merkityksettömän muutospyynnön.
Erottele DKIM :n osalta julkinen vahvistusmateriaali kaikesta yksityisestä allekirjoitusmateriaalista. DNS tietue sisältää julkisen avaimen tiedot. Yksityisiä avaimia ei saa kerätä vastaanottolomakkeelle tai liittää lippuun. Protokolla yhdistää viestin allekirjoituksen allekirjoitusalueeseen ja valitsin; nämä tunnisteet määrittävät, mistä todentaja etsii avainta. Visuaalisesti samankaltainen verkkotunnus tai yleinen tilitunniste ei voi korvata niitä. RFC 6376 , DKIM-Signature ja avainten säilytys
Afrihostin DKIM luontiartikkelissa sanotaan, että tietue voidaan kopioida toimialueen DNS klusteriin, kun ehdotettu tietue on asennettu. Käsittele tätä syynä selvittää, kuka todella palvelee arvovaltaista DNS . Paikallinen isännöintinäkymä ja ulkoisesti toimiva julkinen vyöhyke voivat vaatia erilaisen julkaisun omistajuuden. Älä päättele, että julkinen tietue muuttui vain siksi, että paikallinen käyttöliittymä näytti onnistumisilmoituksen. Afrihost DKIM -sukupolvi
Valmistele SPF muutos hylkäämättä muita lähettäjiä
Dokumentoitu ClientZone-polku on Hosting, verkkotunnus kohdassa Jaettu hosting, Hosting-asetukset, DNS editori ja sitten Luo uusi tietue. SPF :lle artikkelissa määritellään TXT , tyhjä prioriteettikenttä, kopioitu SPF sisältö ja TTL 7200. Tämä käyttöliittymäresepti ei oikeuta luomaan toista SPF käytäntöä, jos sellainen on jo olemassa. Tarkista nykyinen käytäntö ja yhdistä vain hyväksytyt valtuutusmuutokset. Afrihost SPF -julkaisu
SPF arvioi SMTP identiteetin, mukaan lukien POSTIA LÄHETTÄJÄsen sijaan, että luottaisit vain ihmisen luettavaan From-kenttään. Varastosovellukset, jotka lähettävät asiaankuuluvan identiteetin ennen käytäntönsä muokkaamista. Isännöidyillä postilaatikoilla, verkkosivustojen ilmoituksilla ja ulkopuolisella markkinointityökalulla voi olla eri kirjekuoret ja infrastruktuuri. Älä oleta, että cPanel-oletusarvo sisältää kaikki organisaation hyväksymät palvelut. RFC 7208 , HELO ja MAIL FROM identiteetit
Säilytä yksi sovellettava SPF -käytäntö omistajan nimessä. Tarkista sisäkkäiset sisällöt ja muut DNS-kyselytermit protokollan arvioitujen termien rajoituksen perusteella. Lyhyellä huipputason politiikalla voi silti olla liiallinen riippuvuuspolku. Kirjaa muistiin tarkistusmenetelmä ja todisteiden aika, mutta älä merkitse toteuttamatonta suunnitelmaa onnistuneeksi reaaliaikaiseksi arvioimiseksi. Välimuistissa oleva vastaus ei rajoita arviointisääntöjä. RFC 7208 , useita tietueita ja DNS hakurajoitukset
Ratkaise DKIM -omistajan nimen epäselvyys ennen julkaisua
Afrihostin DKIM -julkaisusivulla kuvataan ClientZone-reitti ja DKIM TXT -arvon liittäminen. Sen teksti sisältää kuitenkin SPF-merkityn ohjeotsikon ja yleisen verkkotunnuksen nimikentän täydellisen tilikohtaisen valitsimen omistajan sijaan. Nämä tiedot eivät ole turvallinen perusta huippu DKIM tietueen keksimiselle. Hanki ja tarkista todellisen verkkotunnuksen koko luotu nimi ja arvo ja ratkaise toimittajan nimeämiskäytäntö ennen julkaisun hyväksymistä. Afrihost DKIM -julkaisu
DKIM :ssä valitsin ja allekirjoitustoimialue muodostavat avaimen hakunimen _domainkey kohdan alle. Varsinaisen valitsimen on tultava tilin tuetuista määrityksistä ja vastattava allekirjoitettavia viestejä. Älä anna arvattua valitsinta vain siksi, että toinen palvelu käyttää sitä. Sama sääntö pätee kopioituun julkiseen avaimeen: sen syntaksi yksinään ei varmista, että aiotulla allekirjoittajalla on vastaava yksityinen avain. RFC 6376 , avainten säilytys
Varmista, odottaako editori suhteellista tunnistetta vai täydellistä omistajan nimeä. DNS -päätiedostokäytännöt sisältävät nykyisen alkuperän, mutta graafiset editorit ovat tuoterajapintoja ja tarvitsevat oman tulkinnan. Hyväksymiskriteerinä on tuloksena oleva täysin pätevä omistajan nimi, ei se, onko operaattori kirjoittanut tutun lyhenteen. RFC 1035 , päätiedostomuoto
Tulkitse todennustulokset suppeasti
Jotkin palveluntarjoajan johdantosanat kuvaavat DKIM estävän roskapostin tai parantavan toimitusta. Älä muuta tätä kuvausta takuuksi. DKIM tarjoaa kryptografisen allekirjoituksen ja siihen liittyvän allekirjoitustunnuksen; se ei ole viestin rungon salaus eikä varmista, että kaikki viestin liikeohjeet ovat turvallisia. Kelvollinen allekirjoitus eroaa myös DMARC linjaus. RFC 6376 , johdanto
Varsinaisen lähetysreitin osalta hyväksyntätarkistuksen tulee liittää SPF tai DKIM identiteetti näkyvään tekijän verkkotunnukseen. DMARC voi kulkea kumman tahansa hyväksytyn kohdistetun mekanismin läpi. Erikseen olemassa oleva DNS tietue ei muodosta tätä suhdetta viestille. Todennus ei myöskään takaa toimitusta, ohita vastaanottajien suodatusta tai todista, että tiliä ei ole käytetty väärin. RFC 9989 , tunnisteiden kohdistus ja laajuus
Kuvitteellinen diagnoosi: väärä julkaisun omistaja
Kuvittele kuvitteellinen yhdistys nimeltä Cedar Trail Club. Sen vapaaehtoinen hankkii ehdotetun DKIM tietueen oikeasta cPanel-toimialueesta ja kopioi sitten vain arvon DNS muutospyyntöön. Toinen operaattori olettaa tietueen kuuluvan juureen, koska pyyntö ei sisällä valitsimen omistajaa. Tämä on keksitty suunnitteluskenaario, ei väite Afrihost-asiakkaasta tai täällä tehty testi.
Arvioija hylkää epätäydellisen pyynnön arvaamatta valitsinta. Sovelluksen omistajan on toimitettava koko luotu julkinen tietue ja yksilöitävä suunniteltu allekirjoitusreitti. DNS operaattorin on vahvistettava arvovaltainen vyöhyke ja tuloksena oleva omistajan nimi. Julkaisun omistaja vaatii sitten varsinaisen viestitodisteen, joka on saatu valtuutetun prosessin kautta, ennen kuin hyväksyy allekirjoituksen ja tasauksen. Korjaava oppitunti on säilyttää luodun kontekstin, julkisen avaimen sijainnin ja viestin identiteetin välinen suhde sen sijaan, että liitetty arvo käsitettäisiin täydellisenä kokoonpanona.
Tyhjä toiminnallinen hyväksymistaulukko
Tämä taulukko on ehdotus. Yhtään solua ei esitäytetty keksityllä tilituloksella.
- Isännöintituote, paketti ja verkkotunnuskonteksti: ______
- Valtuutettu cPanel-operaattori ja hyväksyntäviite: ______
- Virallinen DNS palveluntarjoaja ja vyöhykkeen omistaja: ______
- Nykyinen SPF käytäntö ja laillinen lähettäjän luettelo: ______
- Ehdotettu SPF -arvo ja tarkistettu yhdistetty käytäntö: ______
- Täysi luotu DKIM omistajan nimi ja julkinen arvo: ______
- Toimittajan nimen tulkinta ja ristiriitojen tarkistus: ______
- Julkisen tietueen havainnointi, aikaleima ja laajuus: ______
- Todellinen viestin valitsin, allekirjoitustoimialue ja kirjekuoren identiteetti: ______
- Todennus- ja kohdistustodistus: ______
- Peruutus, vastuullinen omistaja ja vapauttamispäätös: ______
Julkaisu- ja toiminnalliset säilytykset
Tilin soveltuvuus, nykyiset tuotteen hallintalaitteet, DNS julkaisu, allekirjoituksen aktivointi ja vastaanotettujen viestien vahvistus ovat avoinna. Tiliä ei käytetty, ehdotettua tietuetta ei ole asennettu, DNS tietuetta ei luotu eikä testiviestiä lähetetty. Ihmisten aiheen tarkastelu, lähteiden soveltuvuus, alkuperäiset luettelotiedot, tuotantoreitit, visuaalinen saavutettavuus ja omistajan luovutus ovat myös avoinna. Luonnos ei korvaa luettelon vaadittua toteutustodistusta tällä kuvitteellisella diagnoosilla tai palveluntarjoajan opetuksen onnistumisen sanamuodolla.