Der DKIM Das l-Tag begrenzt, wie viel vom kanonisierten Körper zum Beitrag beiträgt Körper-Hash. Es kann dazu führen, dass eine Signatur angehängten Inhalt überlebt, aber dieses Überleben kommt dadurch zustande, dass der Inhalt außerhalb des Abdeckungsbereichs der Signatur bleibt. Betrachten Sie es als Sicherheitsentscheidung und nicht als routinemäßige Behebung von Fußzeilenfehlern.
Wissen Sie, wie lang die Länge ist
RFC 6376 Abschnitt 3.5 definiert l als Anzahl der Oktette im kanonisierten Körper. Dabei handelt es sich nicht um die Anzahl der Zeichen, Zeilen oder die Größe eines Anhangs. Kanonisierung geschieht, bevor die Längenbeschränkung angewendet wird. Ohne l ist der gesamte kanonisierte Körper abgedeckt. Ein Wert von Null lässt zu, dass kein Textinhalt zum Hash beiträgt; es bedeutet nicht, dass der Versicherungsschutz unbegrenzt ist.
Wenn l die verfügbare kanonisierte Körperlänge überschreitet, ist die Signatur gemäß den Verifizierungsregeln der Spezifikation ungültig. Die Obergrenze ist die explizite Anforderung in RFC 6376 Abschnitt 3.5. Ein gewöhnlicher Dateigrößenvergleich kann die Abdeckung nicht zuverlässig ermitteln, da sich Übertragungskodierung und Kanonisierung auf die relevante Darstellung auswirken.
Verstehen Sie, warum ein Pass irreführend sein kann
Die Funktion wurde entwickelt, um Ergänzungen wie Mailinglisten-Trailer zu tolerieren. Jedoch, RFC 6376 Abschnitt 8.2 warnt davor, dass angehängte Inhalte MIME Struktur oder das Client-Rendering ausnutzen können, sodass der Empfänger irreführendes Material sieht, während das abgedeckte Präfix intakt bleibt. Eine vorübergehende Signatur stellt daher nicht die Integrität des gesamten angezeigten Körpers dar, wenn l ein Suffix unbedeckt lässt.
Anschauliches Szenario: Ein Unterzeichner deckt ein Anfangskörperpräfix ab. Ein späterer Prozessor hängt Text außerhalb dieses Präfixes an. Die Signatur kann gültig bleiben, wenn das abgedeckte Präfix und die signierten Header unverändert bleiben und andere Überprüfungsprüfungen erfolgreich sind. Dies ist ein Beispiel für die konzeptionelle Abdeckung und kein Beweis dafür, dass jedes MIME Anhängen das gleiche Ergebnis liefert oder dass ein bestimmter Client es sicher rendern wird.
Überprüfen Sie die Richtlinie, bevor Sie sie ändern
Behalten Sie für jede betroffene Signatur die Rohnachricht l, c, h, d und bei Wähler. Verwenden Sie einen konformen Prüfer oder eine bytebewusste Analyse, um die kanonisierte Körperlänge und das abgedeckte Präfix zu bestimmen. Beachten Sie, ob Content-Type und andere interpretierungsrelevante Header ausgewählt wurden. Eine Überprüfung der Header-Abdeckung kann zusätzliche Risiken aufdecken, nicht signierte Textinhalte werden dadurch jedoch nicht signiert.
Überprüfen Sie, ob das Empfängersystem spezielle Richtlinien für Signaturen mit begrenztem Textkörper anwendet. RFC 6376 Abschnitt 8.2 warnt die Unterzeichner, äußerst vorsichtig zu sein, und weist darauf hin, dass Prüfer solche Unterschriften möglicherweise ignorieren. Versprechen Sie nicht, dass eine mathematisch gültige Präfixsignatur überall akzeptiert wird.
Bevorzugen Sie vollständigen Inhalt an der Signaturgrenze
Wenn das Ziel darin besteht, einen ausgehenden Haftungsausschluss zu überleben, überlegen Sie zunächst, den Haftungsausschluss zu verschieben, bevor Sie die endgültige Nachricht mit einer autorisierten Domäne signieren oder signieren. Überprüfen Sie bei Mailinglisten das Änderungs- und Signaturdesign der Liste. Diese Ansätze beziehen sich auf die Verarbeitungsreihenfolge, anstatt das geänderte Suffix vor der Berichterstattung zu verbergen.
Wenn ein Legacy-Workflow immer noch l verwendet, dokumentieren Sie, warum, welche Routen davon abhängen und welche Risiken bei der Empfängerinterpretation bestehen bleiben. Testen Sie das Entfernen oder Ersetzen auf einem kontrollierten Weg mit einem Rollback-Plan. Ändern Sie nicht stillschweigend das Signaturprofil für alle E-Mails, ohne legitime verzögerte und indirekte Routen zu überprüfen.
Machen Sie das Ergebnis der Überprüfung konkret
Im Ergebnis soll festgehalten werden, ob eine Voll- oder Teilkörperabdeckung vorgesehen ist, welche Botschaften diese nutzen und wer das Restrisiko übernommen hat. Bewahren Sie den Nachweis der genauen Unterschrift und der verdeckten Darstellung auf. Eine allgemeine DKIM-Pass-Zählung reicht nicht aus, um diese Überprüfung abzuschließen, da sie nichts darüber aussagt, wie viel Textinhalt die Signatur schützt.
Arbeiten Sie ein Beispiel kanonisierter Länge
Angenommen, ein konformes Tool misst einen kanonisierten Körper von 140 Oktetten und die Signatur hat l=100. Der Body-Hash deckt die ersten 100 Oktette ab; Die restlichen 40 liegen außerhalb der Body-Hash-Abdeckung. Wenn das abgedeckte Präfix und die signierten Header unverändert bleiben, kann die Überprüfung durch weitere angehängte Inhalte erfolgreich verlaufen. Wenn der kanonisierte Text stattdessen nur 80 Oktette mit l=100, verstößt der Wert gegen RFC 6376 Abschnitt 3.5 und die Signatur ist ungültig. Hierbei handelt es sich um konstruierte Zählwerte nach der Kanonisierung, nicht um rohe Dateigrößen oder einen ausgeführten kryptografischen Test.
Führen Sie ein kompaktes Ermittlungsprotokoll
Verwenden Sie dieses vorgeschlagene Arbeitsblatt für die zu prüfende Route. Es handelt sich um eine Planungshilfe, nicht um den Nachweis einer durchgeführten Prüfung.
- Signatur: d, Selektor, c, h und l, oder notieren Sie, dass l fehlt.
- Abdeckung: kanonisierte Körperlänge, abgedecktes Präfix und vorzeichenloses Suffix, gemessen mit einem konformen Tool.
- Interpretation: Inhaltstypabdeckung und Auswirkungen der MIME /Client-Wiedergabe.
- Entscheidung: Teildeckung entfernen, Unterzeichnungsreihenfolge neu gestalten oder eine eng begrenzte Ausnahme dokumentieren.