Aloita vanhasta identiteetistä, älä arvaamasta SPF :stä
Varastomerkintä nimeltä "Roaring Penguins" ei riitä lähettäjän määrittämiseen. Yrityksen historiallinen nimi on Roaring Penguin Software, ja sen tuotteisiin kuului useita CanIt-muunnelmia. Ennen kuin muokkaat DNS ää, selvitä, mitä organisaatio todella käyttää: asennettu laite- tai ohjelmistoversio, isännöity palvelu, jälleenmyyjän hallinnoima reitti tai siirron jälkeen jäljelle jäänyt historiallinen tarra. Tämä artikkeli sisältää tarkastuksen ja todisteiden työnkulun, ei vahvistettua nykyistä käyttöönottoreseptiä.
Yrityksen marraskuussa 2010 julkaisemassa julkaisussa kuvataan CanIt-PRO, CanIt-Domain-PRO ja Hosted CanIt. Se ilmoittaa DKIM tuki suodatuskontekstissa, mukaan lukien allekirjoittajatietojen käyttö postin arvioinnissa. Tämä historiallinen lausunto ei luo nykyaikaista asiakkaan ja verkkotunnuksen allekirjoitusrajapintaa tai SPF mukaan lukien, joka on turvallista julkaista tänään. Roaring Penguin's CanIt 7.0.8 -ilmoitus
Marlinin maaliskuussa 2018 tekemä hankintailmoitus asettaa Roaring Penguinin AppRiverin sähköpostin tietoturvaliiketoimintaan. Hankintahistoria auttaa selittämään vanhoja tarroja, mutta se ei todista, mitä seuraajapalvelua tietty asiakas käyttää, onko sen vanhaa asennusta tuettu tai mitkä DNS ohjeet ovat voimassa. Marlinin hankintailmoitus
Tässä tutkimuksessa ei vahvistettu nykyistä toimittajan omistamaa asennusdokumentaatiota tarkalle vanhalle käyttöönotolle. Vahvistetun nykyisen asennuslähteen puute ei ole todiste tuotteen käytöstä poistamisesta. Älä muuta hakukatkelmia, kolmannen osapuolen peilattuja oppaita tai hankintailmoitusta nykyisiksi tuotantoohjeiksi. Pidä tuote- ja lähdevaraus näkyvissä, kunnes käyttöönoton omistaja toimittaa tuetun viitteen.
Muodosta todellinen postipolku
Aloita järjestelmän omistajasta, palvelusopimuksesta, asennetusta versiosta, hallinnan päätepisteestä ja vastuullisesta tukiorganisaatiosta. Tallenna paikka, jossa nimi esiintyy: postivarasto, SPF mekanismi, MX kohde, vastaanotettu otsikko tai laskutustietue. Nämä vihjeet vastaavat erilaisiin kysymyksiin. Suodattava isäntänimi saapuvassa polussa ei ole todiste siitä, että palvelu on peräisin organisaation lähtevästä sähköpostista.
Piirrä yksinkertainen reittiluettelo vaihtolippuun. Tunnista alkuperäinen sovellus tai postilaatikko, mahdollinen rele tai suodatin, julkinen poistopalvelu ja testaukseen käytetty kohde. Merkitse jokainen hyppy havaituksi, dokumentoiduksi tai edelleen päätellyksi. Jos jälleenmyyjä hallinnoi palvelua, pyydä sitä tunnistamaan taustalla oleva tuote ja sen nykyisen tuen tarkka laajuus olettamatta, että asiakkaalla on toimittajan alkuperäinen hallintaliittymä.
Kerää ohjattu lähtevä viesti ja erikseen kaikki saapuvat esimerkit, joita tarvitaan suodattimen ymmärtämiseen. Käytä vaaratonta sisältöä ja valtuutettuja vastaanottajia. Säilytä aikaleimat ja asiaankuuluvat reititysotsikot henkilökohtaiset tiedot minimoituina. Älä oleta, että otsikko, jossa on tuotteen nimi, on luotettava todiste omistajuudesta. korreloi se organisaation määrittämän reitin ja vastaanottajan omien havaintojen kanssa.
Järjestelmänvalvoja saattaa huomata, että vanha komponentti vastaanottaa vain postia, kun taas lähtevä liikenne lähtee toisen palveluntarjoajan kautta. Siirrä siinä tapauksessa lähtevän todennus varsinaisen lähetyspalvelun oppaaseen. Säilytä vanha komponentti saapuvan palvelun inventaariossa äläkä lisää lähetyslupaa vain saadaksesi jokaisen varastomerkinnän näyttämään "määritetyltä".
Erota allekirjoituksen vahvistaminen allekirjoituksen luomisesta
Saapuvan DKIM tarkistus kysyy, vahvistaako vastaanotettu allekirjoitus. Lähtevä allekirjoitus luo allekirjoituksen viesteille, jotka lähtevät valtuutetusta toimialueesta. Suodatussääntö, joka antaa kelvolliselle allekirjoittajalle alhaisemman roskapostipisteen, ei luo organisaation allekirjoitusta. Historiallinen ilmoitus tukee DKIM-suodatusominaisuuden olemassaoloa, ei tilikohtaista allekirjoitusmenettelyä. Roaring Penguinin historiallinen DKIM ilmoitus
Lähtevän allekirjoitusvaatimuksen yhteydessä vaadi todisteet allekirjoitusjärjestelmästä, verkkotunnuksesta, valitsin, julkisen avaimen julkaisu ja ohimenevä vastaanotettu allekirjoitus. DKIM 'sd= ja s= -arvot identifioivat haussa käytetyn allekirjoitustoimialueen ja valitsimen. Vanhan valitsimen alta löydetty DNS tietue ei osoita, että nykyistä viestiä allekirjoitetaan edelleen sillä. DKIM RFC 6376
Pyydä nykyiseltä operaattorilta tuetut ohjeet, jotka vastaavat asennettua versiota ja käyttöönottomallia. Selvitä, kuka omistaa yksityisen avaimen ja kuinka kiertoa ja palautusta hallitaan ilman itse avainta. Tallenna, muuttavatko alavirran järjestelmät viestejä allekirjoituksen jälkeen. Tee testi ennen hyväksyttyä muutosta ja sen jälkeen, jotta arvioija voi erottaa puuttuvan allekirjoituksen myöhemmin pätemättömästä.
Älä julkaise uutta valitsinta, vaihda julkista avainta tai vaihda allekirjoituksen ohjausobjektia pelkästään vanhan käyttöoppaan perusteella. Jopa historiallisesti autenttinen menettely voi olla väärä muuttuneelle palvelulle tai asennukselle, jota ei tueta. Turvallinen seuraava vaihe on todistepyyntö ja kattava testisuunnitelma, ei arvattu valikkopolku.
Arvioi SPF ja DMARC vain havaituista identiteeteistä
Tunnista lähtevän viestin SMTP -kirjekuorialue ja julkinen poistumispolku. SPF valtuuttaa lähettävät järjestelmät arvioitua SMTP identiteettiä varten; se ei tee saapuvan liikenteen suodatuspalvelusta lähettäjää. Säilytä olemassa oleva laillinen valtuutus, ylläpidä yhtä sovellettavaa SPF -käytäntöä jokaisella omistajalla ja arvioi hakurajat ennen kuin ehdotat vaihtoa. SPF RFC 7208
Täällä ei toimiteta yleistä Roaring Penguin -pakkausta. Hanki nykyiset palveluntarjoajan ohjeet tai järjestelmänvalvojan vahvistamat lähtötiedot tarkasta reitistä. Älä käytä verkkotunnusta uudelleen vain siksi, että se esiintyy arkistoidussa esimerkissä. Tallenna todisteet kunkin ehdotetun luvan liittämisestä aktiiviseen sähköpostiin, mukaan lukien palvelun omistaja, joka voi vahvistaa sen.
Vertaa sitten ohittavaa SPF tai DKIM verkkotunnusta näkyvään Lähettäjä-verkkotunnukseen. DMARC vaatii kulkevan kohdistetun polun, ei vain vanhan tuotteen nimen tai todennuspassin läsnäoloa jossain otsikoissa. Käytä RFC 9989 ja säilyttää vastaanottajan tulos sen selittävien alueiden kanssa. DMARC RFC 9989
Jos reittiä ei voida tukea tai vahvistaa, suunnittele kontrolloitu siirto sähköpostin omistajan kanssa. Varaa ensin kriittiset lähettäjät, määritä korvaava reitti, tarkista linjaus siellä ja asiakirjojen palautus. Älä poista vanhoja tietueita ennen kuin jäljellä oleva liikenne ja riippuvuudet on tarkistettu.
Kuvitteellinen diagnoosi: saapuva suodatin luullaan lähteväksi lähettäjäksi
Kuvitteellinen organisaatio näkee Roaring Penguin -merkinnän postidokumentaatiossaan ja olettaa, että sen on lisättävä uusi SPF sisällys. Tutkija seuraa lähtevää testiä ja huomaa, että vanha suodatin on olemassa vain saapuvassa postissa. Viesti lähtee itse asiassa erikseen hallitun releen kautta. Tämä keksitty skenaario kuvaa varastovirhettä, ei mitattua Roaring Penguinin käyttöönottoa.
Tiimi tarkistaa releen kirjekuoren ja DKIM identiteetit ja antaa todennustyönsä välittäjän omistajalle. Se pitää saapuvan suodattimen tukikysymyksen avoimena, mutta ei tee spekulatiivisia SPF muutoksia. Toisessa tarkastelussa tarkistetaan, käytetäänkö vanhoja allekirjoitusvalitsimia edelleen, ennen kuin poistetaan mitään. Tuloksena on korjattu reittiinventaari ja perusteltu muutossuunnitelma, ei tarpeettoman valtuutuksen aiheuttama vihreä tila.
Legacy-route -laskentataulukko
- Identiteetti: historiallinen etiketti, tarkka tuote, versio, käyttöönottomalli, operaattori ja nykyinen tukiyhteyshenkilö.
- Suunta: saapuvan liikenteen suodatus, lähtevän liikenteen välitys, allekirjoitus tai ratkaisematon; sisältää todisteet jokaisesta luokituksesta.
- Reitti: lähtötyökuorma, välijärjestelmät, julkinen ulostulo, aikaleima ja valtuutettu testin vastaanottaja.
- Todennus: näkyvissä lähteestä, kirjekuoren verkkotunnus, DKIM d=/s= -parit, luotetut tulokset ja kohdistushaku.
- Dokumentaatio: nykyinen toimittajaviite, version soveltuvuus, julkaistut julkiset arvot ja ratkaisemattomat ominaisuudet.
- Siirtymä: tuettu korvaaminen tarvittaessa, tärkeät lähettäjät, palautusomistaja ja eläkkeelle jääminen.
Julkaisuraja
Tämä on täydellinen vanha auditointiehdokas, jossa on selkeä toteutusvaatimus. Nykyistä toimittajakohtaista SPF -arvoa, valitsinta tai liitäntämenettelyä ei ole vahvistettu. Live-käyttöönotto, DNS , otsikko, visuaalinen, ihmisen pk-yritys ja julkaisuportit odottavat. Ennen julkaisua toimittajan on päätettävä, tukevatko ratkaistu todisteet asennusopasta vai pitäisikö aihe pysyä selkeästi merkittynä perintöarviona.
Merkitse historialliset todisteet sillä, mitä se voi vahvistaa
Vuoden 2010 julkaisu perustaa historiallisen suodatusominaisuuden ja vuoden 2018 ilmoitus hankintahistorian. Kumpikaan ei muodosta aktiivista asiakasreittiä, nykyistä tukioikeutta tai seuraavaa allekirjoituskokoonpanoa. Kirjaa ne erillisiksi kysymyksiksi nykyiselle operaattorille; Älä muuta yrityksen historiaa suoritettavaksi DNS reseptiksi.
Erillinen viestien hyväksyminen käytännön käyttöönotosta
Ohjattu kohdistettu SPF tulos voi tyydyttää sanoman arvioinnin, mutta se ei yksin oikeuta siirtämään koko toimialuetta hylättäväksi. RFC 9989 osio 7.4 vaatii kelvollisen DKIM :n verkkotunnusten julkaisemiseen p=reject ja varoittaa epäsuoran postin yhteentoimivuudesta. Inventoi kaikki lailliset lähettäjät ja epäsuorat reitit ennen kuin käytännön omistaja hyväksyy täytäntöönpanon. Tälle artikkelille ei suoritettu DNS muutosta, vuokraajatoimintoa tai vastaanotettujen viestien testiä.