Ett meddelande kan ha en giltig DKIM signatur medan dess avregistreringsfält är osignerade. Det är en meningsfull lucka: en mottagare som verifierar meddelandet har inte nödvändigtvis verifierat den annonserade opt-out-åtgärden. Inspektera signaturens täckning, inte bara en generisk DKIM passera etikett.
Leta reda på signaturen som skyddar operationen
RFC 8058 kräver minst ett giltigt DKIM -signaturskydd List-Unsubscribe och List-Unsubscribe-Post . Båda fälten måste visas i taggen h= för den giltiga signaturen. En saknad obligatorisk signatur är ett skäl för mottagaren att inte erbjuda ett klick avanmälan enligt specifikationen. RFC 8058 avsnitt 4.
Ett meddelande kan ha flera signaturer. Kombinera inte giltigheten av en med rubriktäckning av en annan och kalla paret tillräckligt. Identifiera en enda giltig signatur som täcker de obligatoriska fälten och behåll sedan sin undertecknare, väljare och verifieringsresultat. Detta är separat från att kontrollera vilken signatur som bidrar till DMARC inriktning.
Placera rubrikerna före det relevanta signeringssteget
Kartlägg meddelandets konstruktionspipeline: applikationsmall, listbearbetning, gatewaytransformationer, undertecknare och slutlig utgående rutt. Om en tjänst lägger till avregistreringsfälten efter signering, kan en tidigare signatur förbli giltig utan att täcka dem. Korrigeringen är att placera fälten före lämplig signatur eller se till att en senare giltig signatur täcker dem.
Läs det sista meddelandet. RFC 6376 definierar reglerna för h=-lista och rubrikval, inklusive hur upprepade fältnamn hanteras. En strängsökning efter "list-unsubscribe" var som helst i meddelandet är inte ett täckningstest. Dubblettfält och transformationer kräver noggrann inspektion av den faktiska signaturinmatningen. RFC 6376 avsnitt 3.5 och 5.4.
Särskilj signerade och osignerade ändringar
Föreställ dig ett kontrollerat testmeddelande vars annars giltiga signatur täcker båda avregistreringsfälten. Om du ändrar den signerade URI:n till ett annat värde ändras den signerade inmatningen; under normal DKIM verifiering validerar den ursprungliga signaturen inte längre den ändrade inmatningen. Däremot kan en signatur som utelämnar båda fälten förbli giltig efter att dessa osignerade värden ändras. Detta förklarar varför ett generiskt pass inte kan autentisera alla fält.
Dessa är protokollbaserade förväntningar, inte en exekverad kryptografisk fixtur. Ett verkligt auktoriserat mutationstest kräver exakta originalbytes, den valda signaturen och rätt verifieringsnyckel. En injicerad testnyckel visar endast testets kryptografiska relation, inte offentlig DNS härkomst eller det historiska mottagningsresultatet. Bevara originalet och mutera en separat kopia.
Kontrollera hela den skyltade vägen
Efter att ha fixat täckningen, skicka om ett auktoriserat testmeddelande genom den avsedda rutten och verifiera på den mottagande sidan. Länkomskrivning, gatewayredigeringar eller en senare listprocessor kan ändra ett täckt fält. Bevara pre-transformationen och slutproverna när det är möjligt så att ägaren kan lokalisera det första steget där verifieringen avviker.
Undvik att lösa problemet genom att helt enkelt ta bort fälten från h=. Det kan göra signaturen lättare att bevara samtidigt som RFC 8058 kravet inte är uppfyllt. Om en gateway måste transformera åtgärden, samordna den slutliga signeringsgränsen och se till att den transformerade URI:n fortfarande mappas till rätt mottagare och lista.
Slutför funktionskontrollen
Signaturtäckning autentiserar de annonserade fälten; det bevisar inte att slutpunkten utför den begärda undertryckningen. Använd en kontrollerad prenumeration för att testa POST och nedströms exkludering av nästa sändning separat. Omvänt reparerar inte en fungerande slutpunkt saknad signaturtäckning.
Stängningsposten ska identifiera den giltiga täckande signaturen, det exakta slutliga meddelandet, ändpunktsomfånget och observerade undertryckningsresultat. Behåll leverantörens användargränssnitt som en separat observation snarare än en utlovad konsekvens av korrekt signering.
Behåll en signaturspecifik stängningspost
Spela in det slutliga meddelandet, undertecknaren, väljaren, de två täckta fälten och verifieringsresultatet för just den signaturen. Anteckna slutpunkts- och undertryckningsresultat separat. Om en senare gateway muterar fälten, reparera signeringsgränsen istället för att ta bort den nödvändiga täckningen.