Luokittele reitti ennen kuin päätät, mikä epäonnistui
Vastaanottaja voi nähdä postin suoraan lähettävältä palvelulta edelleenlähetyksen jälkeen tai sen jälkeen, kun postituslista on muokannut sitä. Lähteen IP-osoite ja todennusvirhe eivät sinänsä erota näitä polkuja toisena henkilönä esiintymisestä. Tutkijan on yhdistettävä raportoitu tulos tiettyyn reittiin ja säilytettävä epävarmuus siitä, missä reitti puuttuu. Muutoin lailliselle lähettäjälle tarkoitettu korjaus voi valtuuttaa asiaankuulumattoman infrastruktuurin.
Tämä opas käyttää RFC 9989 ja RFC 9990 toukokuusta 2026 alkaen, SPF RFC 7208 ja kokeellinen ARC spesifikaatio RFC 8617 . Palveluntarjoajan opastus tarkistettiin 8.11.2026. Kaikki reittiesimerkit ovat kuvitteellisia paperikoteloita. Viestiä ei lähetetty, tuotu tai vahvistettu, DNS kyselyä ei suoritettu eikä edelleenlähetys- tai vastaanottajan luottamusasetusta muutettu.
Määritä suora lähetys suhteessa vastaanottorajaan
Tässä tutkimuksessa suoralla lähetyksellä tarkoitetaan sitä, että tarkoitettu lähtevä palvelu toimittaa vastaanottorajalle ilman väliin tulevaa välityspalvelua tutkittavalla reitillä. Se ei tarkoita, että alkuperäisessä organisaatiossa olisi vain yksi sisäinen palvelin. Sisäiset releet ja lähtevät yhdyskäytävät voivat edeltää havaittua yhteyttä, joten merkitse muistiin käytetty raja, kun kiinnität tarraa.
RFC 7208 arvioi yhdistävän isännän määritettyä SMTP identiteettiä vastaan. Suoralla reitillä vika voi olla merkki konfigurointiongelmasta, odottamattomasta polusta tai luvattomasta käytöstä. Pelkän tuloksen perusteella ei riitä syyn nimeäminen. Säilytä arvioitu toimialue, yhteyskonteksti ja virhetila ennen kuin ehdotat muutoksia sen valtuutukseen.
Selitä, miksi edelleenlähetys voi muuttaa SPF todisteita
Kun huolitsija toimittaa alkuperäisen viestin eteenpäin, seuraava vastaanottaja näkee välittäjän yhteysosoitteen. Jos alkuperäinen kirjekuoren identiteetti säilytetään, alkuperäisen toimialueen SPF käytäntö ei välttämättä valtuuta kyseistä osoitetta. Jos kirjekuori kirjoitetaan uudelleen, SPF voi sen sijaan todentaa huolitsijan henkilöllisyyden. Kumpikaan seikka ei tarjoa automaattisesti kohdistettua SPF polkua alkuperäiselle näkyvälle From-verkkotunnukselle RFC 9989.
Tästä syystä jokaisen havaitun huolitsijan lisääminen alkuperäisen toimialueen SPF ään ei ole järkevä oletusvastaus. Se voi laajentaa valtuutusta käsittelemättä todellista reittiä tai muuta todennuspolkua. Selvitä ensin, tapahtuiko edelleenlähetys, odottiko vastaanottaja sitä ja mitkä identiteetit muuttuivat. Edelleenlähetyksen kaltainen kuvio on hypoteesi, kunnes edustavat reittitodisteet tukevat sitä.
Tarkista, säilyikö alkuperäinen DKIM allekirjoitus
Viesti voi säilyttää kelvollisen tasauksen DKIM -allekirjoitus edelleenlähetyksen kautta, jos allekirjoitettu materiaali on edelleen yhteensopivaa todentamisen kanssa. RFC 6376 määrittelee mitä allekirjoitus kattaa ja miten se tarkistetaan. Muutokset allekirjoitettuihin otsikoihin tai tekstin sisältöön voivat rikkoa allekirjoituksen. pelkkä viestin siirtäminen toisen palvelimen kautta ei välttämättä tee sitä. Älä yleistä yhdestä huolintatuotteesta kaikille reiteille.
Postituslista voi muuttaa sisältöä, lisätä alatunnisteen tai muulla tavoin muuttaa viestin ennen uudelleenjakamista. Uusi kelvollinen allekirjoitus luettelosta voi todentaa luettelon toimialueen, vaikka se pysyy erillään alkuperäisen Lähettäjä-verkkotunnuksen kanssa. A raportoi DKIM pass tarvitsee siksi allekirjoitustunnuksensa ja linjaus yhteydessä. Sitä ei voida lukea todisteeksi siitä, että alkuperäisen kirjoittajan verkkotunnus on ohitettu DMARC.
Käytä ARC :tä todisteena, jonka luottamus vaatii vielä päätöksen
RFC 8617 on kokeellinen protokolla todennusarviointien suorittamiseen viestien käsittelyvaiheissa. ARC -ketjun validointi ja luottamus sinetöijiin ovat erillisiä kysymyksiä. Salauskelpoinen ketju ei tee viestistä turvallista tai varmista, että jokainen sulkeja on luotettava. Puuttuva tai katkennut ketju ei myöskään todista, että viesti on väärennetty.
Vastaanottimet voivat käyttää ARC tietoja paikallisissa sijoituspäätöksissä. Älä kirjoita sitä uudelleen universaaliksi säännöksi, jonka mukaan ARC muuttaa taustalla olevan SPF tai DKIM kohdistusvirheen protokollan passiksi. Säilytä havaitut todennustulokset ja raportoidut käytäntöjen ohitukset erikseen. RFC 9990 erottaa DMARC-arvioidut kentät raakatodennuksen tuloksista ja tarjoaa kontekstin käytäntöjen ohituksen raportoinnille. Vastaanottajan hyväksyntä ja todennustulos ovat eri asioita.
Vertaa neljää fiktiivistä polkua ilman yliluokittelua
Säilytetty paperiharjoitus asettaa vastakkain neljän mahdollisuuden: tarkoitettu suora palvelu; muuttumaton kuormatraktori, joka säilyttää kohdistetun DKIM :n; muokkausluettelo, jonka alkuperäinen allekirjoitus ei enää vahvista; ja lähettäjä, joka esiintyy Lähettäjä-verkkotunnuksena ilman tunnettua valtuutettua reittiä. Nämä ovat selittäviä vaihtoehtoja, eivät neljää testattua viestiä. Heille ei ole määritetty todellista isäntä, tiliä tai yrityksen omistajaa.
Kolme ensimmäistä vaihtoehtoa edellyttävät reittikohtaista konfiguraatiota ja viestitodisteita, ennen kuin niitä voidaan käsitellä laillisena havaittuna liikenteenä. Neljäs on edelleen epäilty huijausta kunnes käytettävissä olevat todisteet ja turvallisuusarviointi tukevat tätä luokittelua. Pelkästään todennusvirhe ei voi erottaa muokkausluettelon tapausta toisena henkilönä esiintymisestä. Sitä vastoin todennuksen läpäiseminen ei voi vahvistaa hyvänlaatuista sisältöä tai tällä hetkellä hyväksyttyä liiketoimintatarkoitusta.
Kunnioita vastaanottajan todellista luottamuskokoonpanoa
Microsoftin Luotettu ARC -tiivisteopas on palveluntarjoajakohtainen esimerkki: se kuvaa laillisten, vaadittujen välittäjien valitsemista Microsoft 365 vastaanottokäyttäytymistä varten. Se ei luo yleistä sallittujen luetteloa, toisen palveluntarjoajan käytäntöä tai asiakkaan vuokralaisen konfiguraatiota. Tämä luonnos ei lisää sinetöijää eikä suosittele luottamaan välittäjään vain siksi, että sen nimi on tuttu.
Säilytä tulevaa tutkimusta varten edustava viesti, luotettu vastaanottojäljitys, asiaankuuluvat palvelun asetukset ja vastaanottajan odotettu reitti. Authentication-Results kentät on tulkittava vahvistetun vastaanottavan luottamusrajan sisällä, kuten RFC 8601 selittää. Epäluotettava kopioitu otsikko voi väittää mitä tahansa. Pidä viestien paljastaminen, vastaanottajan tietoturvamuutokset ja tuotannon DNS toiminnot omien ihmisten hyväksymien alaisina.
Vaadi tarkkailtava reitti ennen kuin soitat todistettuun korjaustoimeen
Tarkka imuportti pysyy auki: Tarkista nykyiset ensisijaiset tekniset tiedot ja säilytä työstetty esimerkki ennen luonnosta. Ensisijaiset lähteet ja fiktiiviset vertailut on säilytetty, mutta tilatut alkuperäiset todisteet ovat edelleen poissa: Reitistä tarpeeseen -kartta, jossa on nykyiset toimittajan todisteet ja kontrolloitu testiviesti.
Mahdollisessa kontrolloidussa testissä on käytettävä hyväksyttyä vastaanottajaa ja reittiä, säilytettävä asiaankuuluva diagnostiikka ja erotettava toimitus, todennus ja paikallisten sääntöjen mukainen käsittely. Sen tulisi käsitellä erityistä epävarmuutta sen sijaan, että se lupaa yleistä edelleenlähetysyhteensopivuutta. Säilytä ehdokasluokitus ja seuraava tutkimusvaihe, kunnes todisteita on olemassa. Älä vaadi onnistunutta korjausta, vahvistettua huijausta tai hyväksyttyä lähettäjää pelkkien dokumenttiesimerkkien perusteella.