Lesing Mottatte overskrifter fra bunn til topp læres ofte opp som måten å følge en meldings rute. Den rekkefølgen kan forklare kronologien, men den autentiserer ikke den eldste oppføringen. En avsender kan plassere oppfunnet sporingsfelt i en melding før den første pålitelige mottakeren håndterer den. Start med å finne mottaksgrensen du kan underbygge.
Forstå hvordan spor legges til
SMTP systemer prepper Mottatt sporingsinformasjon når meldinger passerer gjennom dem. Den nyeste oppføringen er derfor normalt nærmest toppen. Et felt kan registrere mottakersystemet, påstått sendevert, tilkoblingsinformasjon, protokoll, køidentifikator og tid. Ikke hver implementering inkluderer den samme valgfrie detaljen. RFC 5321 avsnitt 4.4.
Tilkoblings-IP-en observert av en pålitelig mottaker er et annet bevis enn en klient levert EHLO/ HELO -navn eller et vertsnavn kopiert til nedre overskrifter. Bevar disse distinksjonene i stedet for å vise hvert navn som en bekreftet fysisk hop. En privat adresse eller et internt vertsnavn kan beskrive et legitimt internt segment uten å være offentlig oppløselig.
Etabler det pålitelige segmentet først
Begynn med det endelige mottakssystemet og arbeid bakover gjennom systemer hvis drift og logger er kjent. Identifiser punktet der meldingen kom fra utenfor denne grensen. Korreler det klarerte feltets køidentifikator, tilkoblingspost og tidsstempel med serverlogger. Hvis en gateway drives av en tredjepart, bruk autorisert bevis fra den gatewayen i stedet for å anta at hele kjeden er klarert fordi den siste mottakeren godtok det.
Eldre felt under grensen forblir krav med mindre det bekreftes. En gyldig senere DKIM Resultatet etablerer ikke automatisk hvert tidligere nettverkshopp, og et kjent domene i en sporingslinje som ikke er klarert, er ikke et bevis på at meldingen gikk gjennom den organisasjonen.
Rekonstruer en hypotetisk kjede med tre innganger
Anta at det øverste feltet Mottatt identifiserer et internt relé klokken 10:05 UTC, det neste identifiserer perimetergatewayen klokken 10:03 UTC, og det eldste gjør krav på en bankvert klokken 09:58 UTC. Autoriserte logger bekrefter de to interne håndteringshendelsene og peer-adressen som er observert ved omkretsen. Ingen bevis bekrefter bankens krav.
Den støttede ruten når tilbake til omkretsens observerte likeside, og stopper deretter. Det kjente banknavnet forblir levert tekst. Til og med to-minutters forskjellen mellom interne tidsstempler er bare et tilsynelatende intervall til klokkenøyaktighet og køposter er kontrollert; den tildeler ikke i seg selv en forsinkelse til en server.
Dette er oppfunne felt- og loggforutsetninger, ikke en målt rute eller utført parser. I en faktisk hendelse, ta vare på hvilke bevis som støtter hvert hopp og be den relevante administratoren om manglende poster i stedet for å gjøre den laveste linjen til bevis på opprinnelse.
Bruk timingen forsiktig
Konverter tidsstempler til en konsistent tidssone mens du beholder originalene. Klokker kan være feil, og et tidsstempel i et uklarert felt kan være oppfunnet. Et negativt intervall eller et langt gap er en ledetråd for å undersøke, ikke bevis for manipulering eller den nøyaktige plasseringen av en forsinkelse. Kølogger kan skille ventetid fra klokkeavvik.
Lukk med et rutediagram eller kortordnet liste som merker hvert hopp som observert, bekreftet eller påstått. Identifiser den siste pålitelige grensen, enhver uforklarlig timing og hvilken ekstra kilde som vil løse det. Ikke gjør den tilsynelatende opprinnelige IP-en til en persons identitet eller geografiske sikkerhet.
Bygg en avgrenset ruterekord
- Start med den endelige mottakeren du kan underbygge.
- Match hvert pålitelig hopp til kø- og tilkoblingsposter.
- Hold navn på avsender atskilt fra observerte peer-adresser.
- Behold originale tidssoneverdier og undersøk klokkeforskjeller før du tildeler forsinkelse.
- Stopp ved den ubekreftede grensen; identifisere loggkilden som trengs for å fortsette.