En meddelelse, der ser ud til at have to afsendere, kan involvere flere forskellige ting: et Fra-felt, der indeholder flere forfattere, to separate Fra-felter eller et visningsnavn, der ligner en anden adresse. Det er forskellige parsing- og sikkerhedstilfælde. Et skærmbillede af en mailklients afsenderlinje kan ikke pålideligt skelne dem.
Bevar den oprindelige meddelelseshoved og begynd med dens struktur. Vælg ikke stille den adresse, der passer til en forbigående signatur. Det kan skjule den tvetydighed, som modtageren og modtageren skal forstå.
Adskil felttælling fra adressetælling
RFC 5322 tillader et enkelt Fra-felt med en postkasseliste. Når denne liste indeholder mere end én postkasse, kræves et afsenderfelt med én postkasse. Reglerne for meddelelsesformat angiver stadig ét Fra-felt, så to separate Fra-felter er ikke den samme konstruktion som ét gyldigt flerforfatterfelt.
Afsender identificerer den transmitterende agent i meddelelsesformatmodellen. Det erstatter ikke From-domænet som DMARC's forfatterdomæne. svar-til, Return-Path og et vist navn tjener også forskellige formål.
Bruge gennemgangen af identitetskæden at holde disse roller adskilt, før godkendelse undersøges.
Anvend DMARC domænereglen eksplicit
RFC 9989's normale behandling kræver netop et udtrukket fra domæne. Hvis nul eller mere end et domæne udtrækkes, afsluttes dets almindelige valideringsproces. Specifikationen tillader en modtager at fortsætte i sagen med flere domæner og diskuterer sikkerheds- og behandlingsimplikationerne.
Det er ikke tilladelse for et diagnostisk værktøj til at vælge den mest bekvemme forfatter og rapportere en ukvalificeret succes. Hvis en modtager vælger at evaluere flere domæner, skal den resulterende procedure og dækning registreres.
Afsnit 11.5 diskuterer evaluering af hvert domæne og anvendelse af den stærkeste politik blandt de kontroller, der mislykkes. Den advarer også om, at behandling af et for stort antal domæner kan skabe et ressourceproblem; hvis ikke alle er behandlet, er evalueringen ufuldstændig. Disse er overvejelser om modtagerhåndtering, ikke et løfte om, at ethvert produkt accepterer eller viser sådan post identisk.
Brug kontrollerede sager med mærkede forventninger
Tilfældene nedenfor er syntetiske header-fragmenter. De er ikke udførte tests eller rapporterede modtagerresultater, og hver af dem har brug for resten af en korrekt konstrueret besked i en kontrolleret test.
| Sag | Illustrative felter | Vurdering til registrering |
|---|---|---|
| Enkelt forfatter | Fra: author@example.com | Almindelig ét-domæne-sti, underlagt de resterende besked- og godkendelsestjek |
| Flere forfattere i ét felt | Fra: author@example.com , editor@example.net | Med det påkrævede separate enkelt-postkasse-afsenderfelt kan dette være et gyldigt multi-forfatterformat; flere From-domæner kræver stadig DMARC exceptionel håndteringsanalyse |
| Dupliker fra felter | Et fra felt for example.com og et andet for example.net | Defekt meddelelsesformat; reparer det ikke usynligt, mens du hævder at evaluere den originale besked |
| Adresselignende visningsnavn | Vis tekst, der indeholder en tilsyneladende adresse før en egentlig postkasse | Parse det faktiske postkassedomæne; vurdere visningsrisikoen separat |
For hvert tilfælde skal du beholde den rå fikstur og parser-output. Tæl felter, angiv udtrukne postkasseværdier og optag domæneresultatet, der førte til den valgte behandlingssti. Hvis to postkasser bruger det samme domæne, skal du ikke antage, at mailklientens visning svarer på, hvordan evaluatoren håndterer den multi-forfatterkonstruktion; beholde sit ekstraktionsresultat og teste implementeringen.
Hold godkendelsesbeviser knyttet til den parsede identitet
An SPF eller DKIM pass for ét domæne kan ikke forklare en anden vist identitet uden den påkrævede justering analyse. Bevar alle relevante DKIM d-værdier og betroede modtagerresultater. Behold også de nøjagtige From-bytes, inklusive foldning og kommentarer, så parsen kan reproduceres.
Omskriv ikke originalen Fra til en enkelt forfatter, før du har bekræftet den originale signatur eller undersøgt, hvad det modtagende system så. En omskrevet kopi kan være nyttig som en separat testcase, men mærk den som en modificeret armatur med et andet identitetsspørgsmål.
Et afvist forsøg producerer muligvis aldrig leverede headere. Bevar SMTP svar og modtagelseslogfiler, hvor de er tilgængelige, i stedet for at opfinde en leveret Authentication-Results prøve.
Testpræsentation samt bearbejdning
Sikkerhedsbekymringen omfatter, hvad en modtager ser. Én komponent kan evaluere en konstruktion, mens en mailklient fremhæver en anden tilsyneladende forfatter. I et autoriseret testmiljø skal du sammenligne parser-output, autentificeringsresultat, håndtering og den viste afsenderlinje for nøjagtig den samme fixtur.
Optag softwareversioner og indstillinger med faktiske observationer. Kopier ikke én klients adfærd til et universelt krav. RFC 9989 identificerer konstruktioner med flere domæner som en potentiel måde at undgå normal DMARC behandling på, så et resultat mærket "ikke evalueret" bør ikke præsenteres som "sikkert".
En praktisk udgående konfiguration har generelt gavn af én klar Fra-postkasse til almindelig automatiseret post. Hvor der er behov for ægte multi-forfatterfunktionalitet, skal du bekræfte det relevante format og den understøttede håndtering med de systemer, der vil behandle det, i stedet for at antage, at et påkrævet afsenderfelt løser alle downstream-godkendelsesproblemer.
Undersøgelsen er færdig, når den bevarer den oprindelige syntaks, forklarer beslutningen om det udtrukne domæne og forbinder denne beslutning med faktisk modtagerhåndtering og præsentation. Hold ekstraordinær eller ufuldstændig behandling synlig i stedet for at fremstille et enkelt grønt godkendelsessvar.