Rajoita ohjeet SpamTitan Gateway -allekirjoitukseen
TitanHQ julkaisee tietyn kokoonpanon DKIM SpamTitan Gateway -menettelyssä. Tämä artikkeli noudattaa tätä tuoterajaa. Se ei oleta, että SpamTitan Cloud, Skellig, vain saapuva -käyttöönotto tai jokainen hallitun palvelun versio paljastaa samat säätimet. Vahvista asennettu versio, lisensoidut ominaisuudet ja todellinen lähtevä reitti ennen allekirjoituksen muutoksen hyväksymistä. Postin vastaanottamista varten listattu toimialue ei sinänsä ole todiste siitä, että lähtevät viestit kulkevat yhdyskäytävän läpi tai vastaanottavat asiakkaan verkkotunnuksen allekirjoituksen.
The Yhdyskäytävämenettely sisältää sekä DKIM -allekirjoitusvaiheet että erillisen vanhan DomainKeys-käytäntötietuekeskustelun. Tämä sekoitus on tärkeä täytäntöönpanoraja. Nykyaikainen allekirjoitusavaimen työnkulku voidaan selittää lähteestä, mutta vanha käytäntövaihe vaatii nykyisen tuotteen vahvistuksen. Älä muunna hiljaa vanhaa DomainKeys-terminologiaa a DMARC vaatimus tai väite, että o=-käytännön julkaiseminen luo nykyaikaisen verkkotunnuksen suojauksen.
Tunnista verkkotunnuksen välitys ja avaimen omistajuus
Dokumentoitu navigointi on System Setup, Mail Relay, DKIM . Sivulla luetellaan verkkotunnusvälittäjät. Muokkaa aiottua verkkotunnusta ja avaa DOMAIN KEY -välilehti. Toimenpide vaatii a valitsin nimi, joka erottaa tämän avaimen muista toimialueen avaimista. Valitse tunniste organisaation hyväksytyn nimeämisprosessin kautta ja tarkista olemassa oleva käyttö ennen sen julkaisemista. Ennustettava tunniste ei ole salaisuus, mutta varatun valitsimen uudelleenkäyttö voi korvata riippuvuuden, jota toinen lähettäjä tarvitsee edelleen.
Lähde kuvaa uuden avainparin luomista ja tarjoaa myös olemassa olevan yksityisen avainkentän. Tämä opas ei pyydä, kerää tai suosittele yksityisen avaimen kopioimista lippuun tai jaettuun asiakirjaan. Avaimen luominen tai tuonti on erillinen valtuutettu hallinnollinen toimenpide. Oppaassa luetellaan 1024-bittiset ja 2048-bittinen vaihtoehtoja ja suosittelee pidempää vaihtoehtoa. Vahvista käyttöönotetun tuotteen tuetut kokoonpanot ja nykyiset salausvaatimukset; Älä alenna versiota vain siksi, että DNS -editori näyttää pitkän julkisen arvon hankalasti.
Julkaise luotu julkinen avain kopioimatta esimerkkiä
Luomisen jälkeen lähde ohjaa järjestelmänvalvojan ASETUKSET-välilehteen ja DNS TXT -materiaaliin. Julkaise todellinen julkinen avain valitusta valitsimesta muodostetulla nimellä, _domainkey ja allekirjoitustoimialue. Dokumentaatioon painettu suuri julkinen avain on kuvitus, ei uudelleenkäytettävä tietue. Merkitse muutospyyntöön valittu omistaja ja valvottu viittaus julkaistuun julkiseen arvoon. Mikään yksityinen materiaali ei kuulu julkiseen DNS .
TitanHQ käsittelee ylimääräisen muotoilun poistamista kopioidusta näytöstä. Tulkitse tämä editorin esityksen käsittelemiseksi, ei avaintavujen mielivaltaiseksi muokkaamiseksi. RFC 6376 , kohta 3.6.2.2 määrittää TXT resurssitietueet avainten säilytystä varten. DNS työkalu voi näyttää useita lainattuja merkkijonoja yhdessä TXT tietue; joka eroaa useista kilpailevista tietueista tai arvoon lisätyistä kirjaimellisista lainausmerkeistä. Pyydä DNS järjestelmänvalvojaa tarkistamaan todellinen looginen tietue ja täydellinen omistajan nimi sen sijaan, että hän hyväksyisi syöttöruudun kuvakaappauksen lopulliseksi todisteeksi.
Pidä vanha käytäntö ja testitila erillään DMARC sta
Palveluntarjoajan menettely kuvaa myös TXT -tietuetta kohdassa _domainkey ja sen jälkeen toimialue o=- tai o=~ -arvoilla Policy Records -kohdassa. Se kutsuu tätä nimenomaisesti DomainKeys-käytännöksi. Tämä ei ole DMARC -käytännön sijainti, eikä se korvaa DKIM valitsimen julkista avainta. Koska menettely yhdistää nämä historialliset elementit, varmista ennen sen lisäämistä, onko kyseistä käytäntövaihetta sovellettavissa tarkalleen nykyiseen Gateway-versioon. Säilytä ratkaisematon kysymys julkaisutietueessa sen sijaan, että keksit modernia vaatimusta.
Oppaassa kuvataan erikseen DKIM -testauslippu, t=y, avaintietueessa. Älä sekoita sitä ohjeeseen asettaa DMARC käyttöönotto testaustilaan tai todisteeseen siitä, että vastaanottajat hyväksyvät kaiken postin. DKIM , DMARC ja paikallisen vastaanottimen käsittelyllä on erillinen semantiikka. RFC 9989 , kohta 4.4 selittää linjaus vaaditaan kulkevan todennusidentiteetin ja tekijän verkkotunnuksen välillä. Vanha käytäntölauseke, jonka mukaan posti on allekirjoitettu, ei tarkoita, että tietty allekirjoitus vahvistaa tai tasaa.
Tarkista ennen kuin otat käyttöön ja suunnittele kierto tarkoituksella
TitanHQ:n OPTIONS-työnkulku käyttää Verify-toimintoa DNS TXT -tietueen hakemiseen ja sen vertaamiseen yhdyskäytävän määritettyihin tietoihin. Kun vahvistus onnistuu, Ota käyttöön aktivoi verkkotunnuksen DKIM allekirjoituksen. Käsittele näitä erillisinä tarkistuspisteinä. Julkaistu avain ei todista, että allekirjoitus on käytössä, kun taas valittu allekirjoitusvaihtoehto ei voi vahvistaa puuttuvaa tai yhteensopimatonta julkista tietuetta. Säilytä varmennustulos ja sen aika kuvaamatta sitä vastaanottimen vastaanottotestiksi.
Dokumentaatio suosittelee säännöllistä avainten kiertoa. Käytännön kiertosuunnitelma vaatii muutakin kuin kalenterivälin: tunnista aktiiviset valitsimet, luodut avaimet, jonossa olevat viestit, DNS välimuisti, valtuutetut operaattorit ja palautusehdot. Älä poista aiempaa julkista tietuetta vain siksi, että korvaava avain on luotu. Selvitä, mitä päällekkäisyyttä todellinen postipolku tarvitsee, ja säilytä tätä päätöstä tukevat todisteet. Tämä käsikirjoitus ei ole mitannut jonojen elinikää tai testannut asennetun tuotteen siirtymäkäyttäytymistä, joten toteutustiedot ovat edelleen avoinna.
Tarkista lopullinen lähtevä viesti suodatustunnisteen sijaan
Erikseen valtuutetussa hyväksyntätehtävässä tulisi erottaa yhdyskäytävän kauttakulku, allekirjoitus, validointi ja linjaus. Tarkista allekirjoituksen d=- ja s=-kentät, näkyvä tekijän verkkotunnus ja luotetun vastaanottajan todennustulokset. RFC 6376 , kohta 3.5 määrittää allekirjoituskentät. Tarkista viestiluokat, jotka voivat kulkea eri polkuja, kuten tavallinen postilaatikkoposti, sovellusilmoitukset ja edelleenlähetetty liikenne. Se, että SpamTitan on tarkistanut saapuvan viestin, ei kerro mitään ratkaisevaa siitä, kuinka lähtevä sovellusviesti allekirjoitettiin.
SPF on erillinen arvostelu. RFC 7208 , kohdat 2.4 ja 4.6.4 kuvaile sitä POSTIA LÄHETTÄJÄ identiteetti- ja DNS-riippuvaiset arviointirajat. Tämä lähde ei tarjoa yleistä lähtevää SPF lisäystä jokaiselle SpamTitan-asennukselle, joten sellaista ei ole keksitty tässä. Hanki todellinen valtuutettu lähetysinfrastruktuuri ja tarkista yksi täydellinen käytäntö kyseiselle henkilöllisyydelle. Todennuksen onnistuminen eroaa postilaatikon sijoittamisesta, sisällön turvallisuudesta tai maksupyynnön vastaanottajan hyväksynnästä.
Kuvitteellinen diagnoosi ja tyhjä hyväksymistaulukko
Kuvitteellinen suunnitteluyritys, Alder Instruments, julkaisee uuden valintaavaimen, mutta jättää allekirjoittamisen pois päältä odottaessaan huoltoikkunaa. Sen sisäinen tarkistuslista merkitsee DKIM valmiiksi, koska vahvistus onnistui. Myöhemmässä tarkistuksessa havaitaan, että tarkistuslista sekoitti DNS sopimuksen aktiiviseen allekirjoitukseen. Ehdotettu korjaus on erottaa sallittava hyväksyntä, havaittu konfiguraatiotila ja tulevan vastaanottimen todisteet. Ei ole tarkoitus julkaista dokumentaation esimerkkiavainta tai lisätä sen sijaan vanhaa käytäntötietuetta. Tämän skenaarion taustalla ei ole varsinaista järjestelmä-, viesti- tai DNS hakua.
- Yhdyskäytävätuote, versio, lähtevä reitti ja verkkotunnuksen välitys: ______
- Valitsin omistajuus ja nykyiset riippuvuudet: ______
- Luotu julkinen omistaja/arvoviite ja hyväksytty DNS muutos: ______
- Yksityisen avaimen säilytyspäätös, ilman salaista materiaalia: ______
- Vanhojen DomainKeysin käytännön sovellettavuuspäätös: ______
- Tarkista tulos ja sen jälkeen Ota hyväksyntä/tila: ______
- Pyörityksen päällekkäisyys, palautus ja edellisen valitsimen säilyttäminen: ______
- Luotettu vastaanotetun viestin allekirjoitus ja tasaustodistus: ______
- Muut poikkeukset, arvioija ja julkaisun omistaja: ______
Alkuperäiset toteutustodisteet, nykyisen lähteen soveltuvuus, ihmisen aiheen tarkastelu, tuotantoreitin hyväksyminen, visuaalinen saavutettavuus ja omistajan vapauttaminen ovat avoinna. Avainta ei luotu, asetusta muutettu, DNS tietuetta julkaistu tai viestiä lähetetty. Luettelon laajempaa toteutusvaatimusta ei voida merkitä valmiiksi pelkästään tämän dokumentaarisen työnkulun perusteella.