En indgående besked kan bestå domænegodkendelse og stadig bede modtageren om at gøre noget farligt. Det kan også mislykkes med godkendelse, fordi en legitim rute gik i stykker. Behandl godkendelse som en målt egenskab ved en meddelelse, og anvend derefter det modtagende systems øvrige kontroller og organisationens forretningsverifikationsproces. At kollapse disse trin producerer både falsk tryghed og unødvendig forstyrrelse.
Identificer de tre beslutninger
Den første beslutning er teknisk: var en autentificeret identifikator tilpasset forfatterdomænet under det relevante DMARC regler? Den anden er operationel: hvordan skal dette modtagende miljø håndtere budskabet under hensyntagen til politik og andre signaler? Den tredje er virksomhedsspecifik: Er den anmodede handling legitim og autoriseret? RFC 9989 definerer domænebaseret godkendelse og politik; det gør ikke en forbigående besked til godkendelse af at betale en faktura. DMARC -specifikation.
Notér disse beslutninger i separate felter. For en fakturaændringsanmodning kan godkendelsesfeltet være bestået, håndteringsfeltets karantæne afventer gennemgang og forretningsfeltet ubekræftet. Disse værdier er kompatible. En modtager kan bruge signaler uden for DMARC , og en medarbejder bør følge den uafhængige godkendelsesworkflow, selv når mailen er blevet godkendt.
Brug resultater fra en pålidelig grænse
An Authentication-Results header er kun nyttig, når dens herkomst er forstået. Angribere kan indsætte overskriftstekst i en besked. Den modtagende organisation skal skelne resultater produceret af dens betroede godkendelsestjeneste fra upålidelige påstande. RFC 8601 beskriver denne tillidsgrænse. Godkendelsesresultater.
Bevar den rå besked og det betroede modtagesystems logfiler. Sammenlign det synlige Fra-domæne med hvert verificeret DKIM underskrivende domæne og SPF identitet faktisk vurderet. Undgå at behandle visningsnavnet, Svar-Til-feltet eller et videresendt skærmbillede som det godkendte forfatterdomæne. Hvis meddelelsen blev videresendt, skal du registrere det oprindelige evalueringspunkt og efterfølgende transformationer, før du beslutter, hvilket bevis der gælder.
Sammenlign tre syntetiske anmodninger
Overvej tre hypotetiske meddelelser om betalingsændringer. Den første gør krav på brand.test, men har kun en bestået evil.test-signatur og ingen SPF beståelse; den formodede eneste autentificerede identifikator fejler strengt justering. Den anden bruger brand-pay.test i både From og dens beståede DKIM identitet, så dens modellerede autentificering beståes trods lookalike-bekymringen. Den tredje bruger brand.test konsekvent og består også, hvilket efterlader kontomisbrug eller en uautoriseret anmodning mulig.
Den foreslåede forretningshandling for hver sag er: hold ændringen og uafhængig verificere den. Disse er opfundne autentificeringsinput, ikke kryptografiske eller modtagerresultater. De skrevne sager antager, at de angivne identiteter er de eneste tilgængelige autentificerede identifikatorer, isolerer streng matchning af nøjagtigt domæne og implementerer ikke fuld DMARC opdagelse. Ingen besked, signatur eller modtagertest blev udført. Det demonstrerer, hvorfor forretningshandlingen ikke kan beregnes ud fra autentificeringens boolean alene.
Designhåndtering uden omgåelse af gennemgang
Vælg autoriserede testmeddelelser for hver kontrolsti, og registrer, om systemet har afvist, sat i karantæne, leveret eller senere afhjulpet dem. En leverandørs funktionelabel er ikke bevis for din konfigurerede adfærd. Medtag undtagelser og tillad regler i testen, fordi de kan ændre det effektive resultat. Undgå bred tilladelsesliste blot for at få en ødelagt legitim rute til at passere igennem.
For økonomiske anmodninger, brug en tidligere etableret kontaktkanal. FBI anbefaler uafhængigt at verificere betalingsanmodninger og ændringer af kontooplysninger. Brug ikke kontaktoplysninger introduceret af den mistænkelige besked som den uafhængige kanal. FBI business e-mail kompromitterende vejledning.
Luk en gennemgang med alle tre beslutninger, beviserne for hvert uløst problem. Dette giver mail-teamet mulighed for at reparere godkendelse, mens finans bevarer betalingstilbageholdelsen, eller sikkerhed for at undersøge en forbigående, men mistænkelig besked uden at hævde, at DMARC er defekt.
Kilde og udførelsesgrænse
RFC 9989 afsnit 4.4, 5.3.5 og 5.4 skelne autentificering, justering og håndtering; et pas godkender ikke beskedindhold. De operationelle beslutninger her er scoped anbefalinger og eksplicit hypotetiske eksempler, ikke nye test af en kunde, udbyder eller historisk inventar. Enhver reel ændring kræver sit eget autoriserede omfang, bevarede beviser og ansvarlig beslutning.