Een voettekst kan een correct ondertekend uitgaand bericht omzetten in een DKIM mislukking. De reparatie begint met de verwerkingsvolgorde: identificeer welk systeem het bericht heeft ondertekend, welk systeem de voettekst heeft ingevoegd en welke handtekening de ontvanger heeft geëvalueerd. Als u een andere DNS sleutel publiceert, kan er geen handtekeningomslagtekst worden toegevoegd nadat deze is gemaakt.
Bewijs welke bytes zijn veranderd
Bewaar een gecontroleerd bericht onmiddellijk na ondertekening en een ander bericht na de gateway, met behulp van onbewerkte berichtexport in plaats van gekopieerde tekst van een e-mailclient. Bewaar de originele bestanden. Noteer de d, s, c, h en eventuele l-tags van elke handtekening. Een bericht kan meerdere handtekeningen hebben met verschillende dekking en uitkomsten.
DKIM berekent een hash van het gecanoniseerde lichaam. Bij gewone volledige dekking voegt een nieuwe voettekst inhoudelijke inhoud en wijzigingen toe die hashen. Ontspannen lichaam canonicalisering verwijdert bepaalde witruimteverschillen; het verwijdert geen disclaimer, HTML-blok of nieuw MIME gedeelte. Een body-hash-mismatch betreft de vergeleken body-hash-invoer en -waarden: de body-representatie, c/l-instellingen en bh-waarde. Een beschadigde of onjuist gegenereerde bh, of een implementatiefout van de ondertekenaar/verificateur, kunnen ook een mismatch verklaren. De vergelijking binnen RFC 6376 sectie 6.1.3 bewijst op zichzelf niet dat een poort het lichaam heeft veranderd. Een algemene handtekeningfout kan in plaats daarvan betrekking hebben op een ondertekende header, sleutelopzoeking of handtekeningsyntaxis. RFC 6376 §3.4, RFC 6376 §3.7 En RFC 6376 §6.1 beschrijf die afzonderlijke controles.
Vergelijk de voorbeelden op de grens waar de voettekst wordt toegepast. Inspecteer zowel tekst/plain als tekst/html-delen, MIME grenzen en overdrachtscodering. Een ogenschijnlijk identieke zichtbare voettekst kan op een andere manier worden geserialiseerd. Als de gateway ook van Onderwerp verandert, controleer dan of Onderwerp wordt vermeld in h: alleen het repareren van de hoofdtekst herstelt geen handtekening over een gewijzigde header.
Test de volgorde in plaats van te raden
Illustratief scenario: een applicatie maakt een factuur, de uitgaande server ondertekent deze en een gateway voegt er vervolgens een juridische kennisgeving aan toe. De ontvanger meldt dat de body-hash niet overeenkomt met de handtekening van de applicatie. In een gecontroleerd alternatief voegt de gateway eerst de kennisgeving toe en ondertekent een geautoriseerde ondertekenaar het laatste geserialiseerde bericht. Een passerend resultaat op dat tweede pad ondersteunt de ordediagnose. Dit zijn voorgestelde testwaarnemingen, geen resultaten van een echte huurder.
Gebruik dezelfde berichtvarianten via beide paden, inclusief HTML, platte tekst en een bijlage. Registreer ontvangerauthenticatieresultaten van een vertrouwde grens, het handtekeningdomein en het zichtbare Van-domein. DKIM pas alleen is hiervoor onvoldoende DMARC als de passerende handtekening niet overeenkomt met het auteurdomein. Een niet-gerelateerde gatewayhandtekening kan correct worden geverifieerd zonder dat uitgelijnde pad op te geven.
Kies een eigen ondertekeningsgrens
Het gebruikelijke duurzame ontwerp is om de vereiste inhoudswijzigingen uit te voeren vóór de definitieve geautoriseerde ondertekeningsbewerking. Dat kan betekenen dat de ondertekenaar later moet worden verplaatst, dat de voettekst eerder moet worden ingevoegd, of dat de gateway moet worden geconfigureerd om het uiteindelijke bericht te ondertekenen met behulp van een domein dat door de organisatie wordt beheerd. Bevestig ondersteund gedrag en sleuteleigendom voordat u een ontwerp selecteert. Ga er niet vanuit dat elke gateway ondertekening van aangepaste domeinen ondersteunt.
Als een bestaande handtekening kapot is, herstelt het toevoegen van een nieuwe geldige handtekening de eerdere handtekening niet. Evalueer de nieuwe handtekening op zijn eigen merites en verifieer deze uitlijning afzonderlijk. Schakel de body-length l-tag niet in alleen maar om voetteksten uit de hash-berekening te laten verdwijnen: er blijft een niet-ondertekend achtervoegsel achter en er ontstaat de beveiligingsafweging die wordt beschreven in RFC 6376 §8.2.
Sluit af met een regressiecontrole
Houd een routediagram bij met het laatste lichaamsveranderende onderdeel en de ondertekenaar direct erna. Test opnieuw wanneer de disclaimerregels, het herschrijven van antivirusprogramma's of wijzigingen in de uitgaande routering plaatsvinden. Succes betekent dat de vereiste voettekst aanwezig is, dat de beoogde handtekening wordt geverifieerd, dat het domein voldoet aan het beoogde uitlijningsbeleid en dat kritieke berichten nog steeds via de verwachte route aankomen. Houd een rollback-plan bij voor de configuratiewijziging, zonder het verwijderen van een vereiste juridische kennisgeving als een automatische oplossing te beschouwen.
Gebruik een regressie-acceptatierecord
Voor elke synthetische platte tekst-, HTML- en bijlagevariant noteert u: voettekst aanwezig; laatste lichaamsveranderende hop; eindondertekenaar d/s; geselecteerde c/u/l; resultaat vertrouwde ontvanger; Auteurdomein en afstemming; en de uitkomst van de zakelijke route. Als de voettekst ontbreekt, wordt niet aan de kennisgevingsvereiste voldaan, zelfs niet als DKIM slaagt. Als de voettekst aanwezig is, maar alleen een niet-gerelateerd gatewaydomein passeert, wordt niet voldaan aan de beoogde DKIM-uitlijningsvereiste. Dit zijn acceptatiecriteria, geen afgeronde controles.