En internationaliserad avsändare kan se annorlunda ut i en e-postklient, en rå header, ett DNS verktyg och ett autentiseringsresultat. En korrekt undersökning förklarar dessa representationer innan man beslutar att identiteterna skiljer sig åt.
Jämför inte bara texten som återges på skärmen. Behåll den råa rubriken och den extraherade domänen, identifiera tillämpliga internationaliseringsregler och registrera DNS formuläret som används för policyupptäckt och identitetsjämförelse. En konvertering som används för utvärdering är en annan operation än att skriva om ett signerat meddelande.
Separera tre delar av adressen
Ett visningsnamn är den mänskliga etiketten. Postlådans lokala del är delen före @. Domänen är delen efter @. De har olika regler och olika roller i autentisering.
Internationaliserade e-poststandarder tillåter system som stöds att transportera UTF-8-huvudinnehåll och postlådenamn med SMTPUTF8. IDNA adresserar internationaliserade domänetiketter; det gör inte en Unicode-postlåda lokal del till ett DNS namn.
DMARCs centrala identitet är Författardomänen extraherad från From. Att ändra stavningen av en persons lokala del skapar inte en ny DMARC inriktning läge och autentisering av domänen bekräftar inte personen eller innebörden av visningsnamnet.
Håll Unicode- och DNS representationerna tillsammans
IDNA skiljer Unicode U-etiketter från deras ASCII A-etikett representation. En giltig A-etikett kan kännas igen av dess xn-- prefix, men ett prefix ensamt bevisar inte att en godtycklig sträng är en giltig kodning. Använd en implementering av tillämpliga IDNA-regler snarare än en handredigerad substitution.
RFC 9989 Avsnitt 5.3.1 kräver konvertering av en U-label Author Domain till A-label form för vidare DMARC bearbetning. Det betyder att en visuellt annorlunda rubrik och DNS namn kan representera samma domän. Det betyder inte att liknande Unicode-tecken i två orelaterade namn blir likvärdiga.
Följande exempel är syntetiskt och använder det reserverade .example-namnområdet. Ingen DNS publicering, meddelandeleverans eller mottagarresultat görs anspråk på.
- Objekt: Från brevlåda med Unicode-domän; Illustrativt värde: info@bü cher.example ; Syfte: Rå internationaliserad header-identitet
- Objekt: Motsvarande A-label domän; Illustrativt värde: xn--bcher-kva.example ; Syfte: Domänformulär för DMARC -behandlingen som beskrivs här
- Objekt: Direkt DMARC uppslagsnamn; Illustrativt värde: _dmarc.xn--bcher-kva.example ; Syfte: TXT fråga för den författaredomänen
- Objekt: Motsvarande brevlådeformulär för ASCII-domän; Illustrativt värde: info@xn--bcher-kva.example ; Syfte: Samma domänrepresentation i ASCII-form
- giltigt godkänt DKIM identitet som använder samma A-label-domän kan jämföras med den konverterade författaredomänen. Om de är identiska kan domänjämförelsen uppfylla strikt anpassning. Ett komplett DMARC pass kräver fortfarande en giltig tillämplig policy och en godkänd anpassad autentiseringsväg; själva konverteringen är inte autentisering.
Använd inte domänkodning på den lokala delen
Överväg en hypotetisk postlåda med en Unicode-lokal del på samma internationaliserade domän. Domänen kan ha en A-label representation, medan den lokala delen förblir en postlådeidentifierare som styrs av internationaliserad e-posthantering. Att använda Punycode på hela adressen är fel modell.
Kontrollera SMTPUTF8-stödet för den faktiska transportvägen när meddelandet kräver det. En domän skriven helt i ASCII A-etikettform kräver i sig inte SMTPUTF8; annan adress eller rubrikinnehåll kan fortfarande göra det. En UTF-8 rå header eller icke-ASCII postlåda lokal del introducerar en separat transport- och parserkompatibilitetsfråga.
Håll dessa resultat åtskilda: oförmåga att transportera ett internationaliserat meddelande, misslyckande att analysera dess identitet, misslyckande att upptäcka policy och misslyckande med autentisering är olika stadier. En ändring av en DMARC tagg kan inte lösa alla.
Bevara signerat innehåll under utredningen
Behåll de ursprungliga meddelandebytena och relevanta signaturer. Att konvertera en extraherad domän för en jämförelse kräver inte att du ersätter Från header i det ursprungliga meddelandet. Att skriva om rubriken och sedan verifiera den modifierade kopian kan ge en annan signaturfråga.
Spela in biblioteket eller produktversionen som utför IDNA- och e-postparsning, dess standarder som stöds och konverteringsresultatet. Behåll eventuell kontrollerad reparation som en separat testfixtur. Undvik att lova att varje leverantör, gateway och klient stödjer samma internationaliserade arbetsflöde utan att testa den vägen.
DMARC taggnamn och definierade värden fortsätter att följa sin angivna syntax. Översätt inte v=DMARC1 eller uppfinn en Unicode-specifik policyversion. För internationaliserade rapportdestinationer eller leverantörsgenererade inställningar, följ tillämpliga URI-, DNS och leverantörsregler istället för att anta att stöd för postlådevisning tillåter godtycklig Unicode i varje konfigurationsfält.
Separera visuell imitation från justering
Ett visat namn kan likna ett bekant varumärke samtidigt som det representerar en annan underliggande domän. IDNA-konvertering förklarar domänrepresentation; det är inte en bedömning att namnet är legitimt eller att två visuellt lika namn är samma identitet.
När du granskar misstänkt post, jämför de faktiska domänerna och deras DNS formulär med det godkända identitetsregistret. Behåll resultat av visningsnamn och lookalike-domän bredvid, men åtskilda från, DMARC -resultatet. Guiden för autentisering mot auktorisering förklarar varför ett giltigt domänresultat inte kan godkänna meddelandeavsikt.
Håll en reproducerbar identitetsjournal
För en riktig undersökning, behåll den visade avsändaren, rå Från-fält, extraherad Unicode-domän, validerad A-etikettkonvertering, policyuppslagsnamn, SPF och DKIM identiteter, betrodda mottagarresultat och transportbevis. Redigera personuppgifter utan att förstöra domänrepresentationen som behövs för att reproducera beslutet.
Ett användbart resultat kan säga att två representationer mappade till samma domän, eller att de var distinkta, och visa hur det påverkade den faktiska utvärderingen. Bevara konverteringen och det ursprungliga meddelandet så att en annan granskare kan komma till samma slutsats.
Spela in konverteringen utan att uppfinna autentisering
Skriftligt fall IDN-01 behåller Från info@bü cher.example och dess motsvarande domän xn--bcher-kva.example . E-postadministratören registrerar tillämpligt IDNA-bibliotek/version och bevarar råmeddelandet separat. SPF , DKIM -verifiering, SMTPUTF8-förhandling och upptäckt policy förblir okända i det här fallet. Nästa steg är att samla in dessa observationer, inte markera meddelandet som autentiserat eftersom de två domänrepresentationerna överensstämmer. Inget meddelande eller DNS förfrågan kördes.