Separera den synliga signaturen från den kryptografiska
En e-signaturtjänst lägger vanligtvis till synligt material som en persons kontaktuppgifter, företagets logotyp eller juridiska formuleringar. DKIM lägger till en kryptografisk rubrik som binder valt meddelandeinnehåll till en signeringsdomän. Det delade ordet "signatur" gör inte dessa operationer utbytbara. Nyckelfrågan är om synligt innehåll infogas före eller efter DKIM signatur som mottagaren utvärderar.
Inget signaturservicekonto, anslutare eller rå kundmeddelande undersöktes här. Den här artikeln ger en diagnostisk plan och ett fiktivt ordningsexempel. Den ursprungliga bevisporten förblir öppen: Original och modifierade råmeddelanden, undertecknarens placering och ett före- och efterverifieringstest. Samla in dessa innan du tillskriver en incident till en tjänst.
Leta upp var det synliga materialet är infört
En användares e-postprogram kan infoga en signatur under sammansättningen. En tjänst på serversidan kan istället ta emot ett skickat meddelande, lägga till innehåll och skicka det vidare. Andra arbetsflöden kombinerar klientinfogning med reservserver. Dessa är möjliga design, inte universellt produktbeteende. Fråga efter den specifika integrationen som stöds och den rutt som faktiskt används av den berörda avsändaren.
Microsofts dokumentation särskiljer användartillämpade signaturer från organisationsomfattande e-postflödesregler som lägger till signaturer, sidfötter eller sidhuvuden. Det visar att insättningsplatsen kan skilja sig även inom en välbekant plattform. Den fastställer inte den relativa ordningen för en okänd tredjepartstjänst och en organisations DKIM undertecknare. Behåll leverantörens tillämpliga integrationsvägledning och verifiera den distribuerade sekvensen separat. Microsoft meddelandetillägg
Läs signaturen som faktiskt misslyckades
Spela in DKIM -signeringsdomänen, väljare, kanonisering och undertecknad rubriklista för varje närvarande signatur. Ett meddelande kan innehålla signaturer från flera behandlingssteg, och var och en måste bedömas oberoende. Sammanfatta inte en misslyckad originalsignatur och en giltig leverantörssignatur som ett enda oförklarat " DKIM problem". Bevara resultatet och domänen för varje kontroll. RFC 6376 avsnitt 3.5 och 4.2
För brödtexten, jämför byten efter den valda kanoniseringen, inte bara utseendet på e-postmeddelandet. Avslappnad kanonisering av kroppen normaliserar specificerat blanksteg; den raderar inte en logotyp, en ny HTML-tabell eller en ändrad länk. Omvänt behöver en ändring som enbart består av tolererat blanksteg inte ogiltigförklara den signaturen. Kontrollera eventuell l= kroppslängdsgräns när du beskriver täckning, men föreslå inte att nyligen bifogat företagsinnehåll osignerat som standardreparation. RFC 6376 avsnitt 3.4 och 8.2
Jämför MIME formulär och ruttvarianter
Ett meddelande kan innehålla vanlig text och HTML-alternativ, inbäddade bilder och bilagor. Ett tillägg på serversidan kan ändra mer än den del som visas av en e-postklient. Fånga oförändrade råmeddelanden vid relevanta gränser och jämför MIME struktur, kodning och den resulterande kanoniserade kroppen. En bild som ser identisk ut på skärmen kan fortfarande åtfölja ett annat serialiserat meddelande.
Inkludera de vägar som är viktiga för organisationen: skrivbordssammansättning, mobilsändning, delade adresssvar och automatiserade applikationer där det är tillämpligt. Deras vägar kan skilja sig åt. En passning på ett skrivbordsmeddelande kan inte bevisa att ett mobilmeddelande använde samma undertecknare eller undvek en andra infogning. Registrera okända rutter som luckor snarare än att uppfinna leverantörsstandarder för att fylla dem.
Arbeta igenom en fiktiv dubbelinsättning
Föreställ dig att fiktiva example.com förbereder ett meddelande som innehåller en textsignatur som lagts till av användaren. Dess utgående undertecknare tillämpar en helkropps DKIM signatur med d=example.com. En senare tjänst lägger till en centralt hanterad HTML-signatur före extern leverans. Antag att ingångssignaturen verifieras och att det tillagda materialet ändrar den kanoniserade kroppen. Den ursprungliga signaturen misslyckas sedan med verifiering på den modifierade representationen. Detta är ett konstruerat exempel, inte en avrättad rättegång.
Anta att tjänsten också signerar med d=signature-service.example medan den synliga From förblir person@example.com . Den nya signaturen kan vara giltig utan att stämma överens med författarens domän. DMARC utvärderar justerade autentiserade identifierare, inte vilken signatur som lades till senast. En separat anpassad SPF Resultatet kan fortfarande ge en väg som passerar, så den misslyckade ursprungliga DKIM signaturen ensam är inte en fullständig DMARC diagnos. RFC 9989 avsnitt 3.2.10 och 5.3
Granska signeringsordern utan att ge ny behörighet
För legitim utgående e-post example.com kan en föreslagen integration slutföra infogning av synligt innehåll innan en auktoriserad example.com undertecknare bearbetar det slutliga meddelandet. En annan arkitektur som stöds kan ha en lämplig auktoriserad tjänst som utför anpassad signering efter dess tillägg. Vilket alternativ som är tillgängligt beror på dokumenterat produktbeteende och den faktiska hyresgästens design; varken har konfigurerats av den här artikeln. RFC 6376 avsnitt 5.1
Att ändra signeringsordning skiljer sig från att ge en leverantör privat nyckelmaterial eller breda reläbehörigheter. Identifiera ansvarig domän, godkänd identitet och autentiseringsgräns innan du föreslår en distribution. Att lägga till en leverantör till SPF reparerar inte en ändrad DKIM body hash, och det gör inte automatiskt att en icke-relaterad kuvertidentitet justeras. Håll kuvertauktorisering och meddelandesignaturintegritet som distinkta uppgifter. RFC 7208 avsnitt 2.4 RFC 9989 avsnitt 3.2.4
Verifiera både utseende och autentisering
Godkännandeplanen bör inkludera avsedd varumärkesprofilering, frånvaro av dubbla tillägg, korrekta länkar och läsbar oformaterad text tillsammans med kryptografiska kontroller. Ett visuellt attraktivt resultat kan misslyckas med autentisering, och en giltig signatur kan täcka fel företagssidfot. Tilldela separata ägare för innehållsgodkännande och e-postautentisering så att ingetdera kriteriet tyst ersätter det andra.
Efter ett separat auktoriserat test, behåll de ursprungliga och slutliga råproverna, ruttbevis, relevant offentlig nyckelkontext och verifieringsresultat per signatur. Använda Authentication-Results endast från en identifierad betrodd utvärderare; ett kopierat fält är inte ett bevis på det slutliga meddelandets integritet. Detta paket innehåller inga sådana operativa prover eller avslutad kontospecifik validering. RFC 8601 avsnitt 7