En IP-adresse er en viktig ledetråd, men det er ikke en fullstendig beskrivelse av en melding. Microsoft Smart Network Data Services kan vise mønstre knyttet til sending av IP-er. Administratorens oppgave er å koble bevisene til applikasjonene, leietakerne og tidsvinduene som faktisk bruker disse adressene.
Begynn ved gjeldende portal
Den nåværende Microsoft-portalen erstatter den eldre senderstøtteposisjonen og inkluderer JMRP-administrasjon. SNDS-tilgang gis for IP-plass som rekvirenten er autorisert til å administrere. Den nåværende kunngjøringen forklarer også periodisk nettverksreattestering. Bruk gjeldende tilgangsside og registrert utløp i stedet for å behandle en gammel vellykket pålogging som permanent tillatelse. SNDS portal.
Hvis en e-posttjeneste eier en delt pool, må du samarbeide med den tjenesten for å finne relevant bevis. Å vite at en melding brukte en IP, etablerer ikke i seg selv autoritet til å se all trafikk knyttet til den. Unngå å eksportere andre leietakers data til en bred hendelsesbillett.
Ta vare på omfanget av observasjonen
Microsofts FAQ beskriver aktivitet på IP-nivå og bemerker at lavvolum IP-data kan være fraværende. Den forklarer også at NAT kan skjule flere maskiner bak én synlig adresse. Registrer den nøyaktige IP-en, den rapporterte aktivitetsperioden og tidskonvensjonen, sammen med hentetiden. SNDS vanlige spørsmål.
Konverter tidssoner nøye før du kobler disse dataene til applikasjonslogger. Behold det originale tidsstempelet og tidssonen samt en normalisert representasjon. En hendelse som krysser midnatt kan falle i forskjellige daglige bøtter i to systemer, og skape et falskt inntrykk av at en dashbordhendelse gikk foran sendingen som forårsaket den.
Bli med IP-telemetri for å rute eierskap
Oppretthold et datert kart over utgående IP-er til sendetjenester og bassenger. Inkluder endringer i allokering, NAT og leverandørruting. Et gjeldende rutekart er utilstrekkelig for en hendelse fra forrige uke dersom leverandøren flyttet trafikken i går. Der utvalget er delt, merk grensen: du kan kanskje kjenne dine egne bidrag uten å se alle andre avsenderes bidrag.
Sammenlign faktisk SMTP -diagnostikk, autentiserte identiteter og klagebehandlingsbevis. SNDS erstatter ikke en autentiseringskontroll på meldingsnivå eller oppretter en endelig postboksmappe. Det er heller ikke et universelt bilde av alle Microsoft-bedrifter. Hold mottakstjenesten og hendelsesomfanget eksplisitt.
Undersøk eksempelet på lokal attribusjon
Det syntetiske armaturet kartlegger to strømmer, kvitteringer og kampanjer, til dokumentasjonen IP 192.0.2.42 i løpet av ett oppfunnet aktivitetsvindu. En degradert observasjon på IP-nivå er knyttet til den adressen. Resultatet viser begge strømmene som kandidater for undersøkelse, ikke bare kampanjen som er nærmest i tid.
En senere ruterekord flytter kampanjer til 192.0.2.43 . Modellen holder den historiske kartleggingen intakt, så en senere eksport omskriver ikke eierskapet til den tidligere hendelsen. Dette er en utført sammenføyning over oppfunnet data, ikke en Microsoft-dashbordeksport eller en omdømmevurdering på de reserverte eksempeladressene.
Eskaler med en avgrenset hendelsespakke
Gi avsenderstøtte eller tjenesteeier relevant datoperiode, IP, nøyaktig SMTP diagnostikk, berørt destinasjonstjeneste og trinn som allerede er sjekket. Rediger mottakerinnhold og tokens som ikke er nødvendig for å diagnostisere problemet. Hold registreringsproblemer atskilt fra leveringsstøtte; FAQ leder disse spørsmålene gjennom forskjellige veier.
En god stenging identifiserer den defekte ruten eller bevarer den gjenværende usikkerheten. En IP-trend kan rettferdiggjøre etterforskning, men den kan ikke i seg selv bevise at en bestemt abonnent klaget, at en spesifikk melding mislyktes med autentisering eller at hver melding gikk til spam.
Les en feltordbok før du kobler til dataene
Microsofts gjeldende FAQ gir feltbetydningene nedenfor. IP-adressen er den synlige kilden, potensielt delt eller bak NAT. Aktivitetsperioden er den første og siste aktivitetstimen på stillehavsdagen; dokumentasjonen sier PST inkludert sommertid-justeringer, så behold den faktiske datoen og Pacific offset i stedet for å bruke en fast UTC-subtraksjon. RCPT-antall beskriver mottakerkommandoer; DATA telling beskriver melding-data kommandoer; meldingsmottakere beskriver mottakere på meldinger som faktisk er overført. Ingen er en telling av personer som leser e-posten.
Filterresultatet oppsummerer spamfilterbeslutninger over IP-trafikk og beskriver ikke direkte plassering av innboks eller søppelmapper. Klagesats bruker klager delt på meldingsmottakere, med klager registrert på dagen rapportert i stedet for flyttet tilbake til den opprinnelige sendedatoen. En sen klage kan derfor dukke opp mot en annen dags avsenderpopulasjon. Data med lavt volum kan være fraværende; Vanlige spørsmål advarer spesifikt om IP-er under hundre meldinger på en dag. En felleindikator er ikke til stede i gjeldende feltliste som brukes her: behold den som utilgjengelig, ikke null, og ikke importer en gammel feltdefinisjon.
I den oppfunne bearbeidede raden produserer 120 RCPT-kommandoer, åtti DATA-kommandoer og hundre meldingsmottakere en forskjell på tjuekommandoer RCPT/mottaker. To rapporterte klager delt på hundre gir 2 % for den syntetiske raden, ikke en måling av misnøye med gjeldende kampanje. Den neste handlingen er en gjennomgang av mottakerhygiene og historisk rute, etterfulgt av klagekorrelasjon hvis tilgjengelig. Gul filtrering ber om gjennomgang av den samlede observasjonen; det oppretter ikke en mappe. Behold Pacific-aktivitetsvinduet og original-send tidsstempler separat når du setter sammen hendelsespakken.