考察
SignHeadersは署名するヘッダーの指定。
OversignHeadersはヘッダ追加を検知し認証失敗させるもの。
例) fromヘッダが途中MTAで追加され2つある場合
OversignHeadersがemptyの場合
単一ヘッダで検証
送信時点の署名対象: 送信時指定のFromの値
途中MTA追加後の署名対象: 送信時指定のFromの値(追加Fromの値は対象にならない)
→Fromが追加されたが検証成功してしまう。
OversignHeadersがFromの場合
Fromは2個あるとみなし検証
送信時点の署名対象: 送信時指定のFromの値、Null(2個目ないので)
途中MTA追加後の署名対象: 送信時指定のFromの値、追加Fromの値
→上記は異なるので、追加を検知可能になる。
SignHeaders
Specifies the set of header fields that should be included when generating signatures. If the list omits any header field that is mandated by the DKIM specification, those fields are implicitly added. By default, those fields listed in the DKIM specification as "SHOULD" be signed (RFC6376, Section 5.4) will be signed by the filter. See the OmitHeaders configuration option for more information about the format and interpretation of this field
署名を生成するときに含める必要があるヘッダーフィールドのセットを指定します。リストでDKIM仕様で義務付けられているヘッダーフィールドが省略されている場合、それらのフィールドは暗黙的に追加されます。デフォルトでは、DKIM仕様で「SHOULD」としてリストされているフィールドに署名する必要があります（RFC6376、セクション5.4）は、フィルターによって署名されます。このフィールドの形式と解釈の詳細については、OmitHeaders構成オプションを参照してください。
OversignHeaders
Specifies a set of header fields that should be included in all signature header lists (the "h=" tag) once more than the number of times they were actually present in the signed message. The set is empty by default. The purpose of this, and especially of listing an absent header field, is to prevent the addition of important fields between the signer and the verifier. Since the verifier would include that header field when performing verification if it had been added by an intermediary, the signed message and the verified message were different and the verification would fail. Note that listing a field name here and not listing it in the SignHeaders list is likely to generate invalid signatures.
すべての署名ヘッダーリスト（ "h ="タグ）に含まれるヘッダーフィールドのセットを、署名されたメッセージに実際に存在した回数よりも1回多く指定します。デフォルトでは、このセットは空です。これの目的、特に不在のヘッダーフィールドをリストする目的は、署名者と検証者の間に重要なフィールドが追加されるのを防ぐことです。検証者は、仲介者によって追加された場合、検証の実行時にそのヘッダーフィールドを含めるため、署名されたメッセージと検証されたメッセージは異なり、検証は失敗します。ここにフィールド名をリストし、SignHeadersリストにリストしないと、無効な署名が生成される可能性が高いことに注意してください。
考察
Pro Linux System Administration: Learn to Build Systems for Your Business ... - Dennis Matotek, James Turnbull, Peter Lieverdink - Google ブックス
DKIM Postfix Setup | CYBERPUNK
説明&上記を見ると、SignHeadersとOversignHeadersは同じものを設定するよう。
ただ、よく意味が分からない。。。RFCを見ると、、、
5.4. Determine the Header Fields to Sign
The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field). Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit. In particular, [RFC5321] explicitly permits modification or removal of the Return-Path header field in transit. Signers MAY include any other header fields present at the time of signing at the discretion of the Signer.
Fromヘッダーフィールドに署名する必要があります（つまり、結果のDKIM-Signatureヘッダーフィールドの「h =」タグに含める必要があります）。署名者は、送信中に正当に変更または削除される可能性が高い既存のヘッダーフィールドに署名しないでください。特に、[RFC5321]は、転送中のReturn-Pathヘッダーフィールドの変更または削除を明示的に許可します。署名者は、署名者の裁量で署名するときに存在する他のヘッダーフィールドを含めることができます。
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to sign is non-obvious. One strategy is to sign all existing, non-repeatable header fields. An alternative strategy is to sign only header fields that are likely to be displayed to or otherwise be likely to affect the processing of the message at the receiver. A third strategy is to sign only "well-known" headers. Note that Verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. For this reason, signing fields present in the message such as Date, Subject, Reply-To, Sender, and all MIME header fields are highly advised.
有益な操作注：署名するヘッダーフィールドの選択は明白ではありません。 1つの戦略は、既存のすべての繰り返し不可能なヘッダーフィールドに署名することです。代替戦略は、表示される可能性が高いヘッダーフィールドのみに署名するか、そうでなければ受信者でのメッセージの処理に影響を与える可能性があります。 3番目の戦略は、「既知の」ヘッダーのみに署名することです。検証者は、エンドユーザーへの表示を拒否したり、特定のヘッダーフィールドをカバーしていない場合は署名を無視したりするなど、署名されていないヘッダーフィールドを極端に懐疑的に扱う場合があります。このため、Date、Subject、Reply-To、Sender、およびすべてのMIMEヘッダーフィールドなど、メッセージに存在する署名フィールドを強くお勧めします。
The DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed.
DKIM-Signatureヘッダーフィールドは常に暗黙的に署名され、他の既存の署名も署名されていることを示す場合を除き、「h =」タグに含めることはできません。
Signers MAY claim to have signed header fields that do not exist (that is, Signers MAY include the header field name in the "h=" tag even if that header field does not exist in the message). When computing the signature, the nonexisting header field MUST be treated as the null string (including the header field name, header field value, all punctuation, and the trailing CRLF).
署名者は、存在しない署名済みヘッダーフィールドがあると主張することができます（つまり、署名者は、ヘッダーフィールドがメッセージに存在しない場合でも、ヘッダーフィールド名を "h ="タグに含めることができます）。署名を計算するとき、存在しないヘッダーフィールドは、null文字列（ヘッダーフィールド名、ヘッダーフィールド値、すべての句読点、末尾のCRLFを含む）として扱われなければなりません。
INFORMATIVE RATIONALE: This allows Signers to explicitly assert the absence of a header field; if that header field is added later, the signature will fail.
有益な根拠：これにより、署名者はヘッダーフィールドがないことを明示的に主張できます。そのヘッダーフィールドが後で追加された場合、署名は失敗します。
INFORMATIVE NOTE: A header field name need only be listed once more than the actual number of that header field in a message at the time of signing in order to prevent any further additions. For example, if there is a single Comments header field at the time of signing, listing Comments twice in the "h=" tag is sufficient to prevent any number of Comments header fields from being appended; it is not necessary (but is legal) to list Comments three or more times in the "h=" tag.
有益な注意：ヘッダーフィールド名は、それ以上の追加を防ぐために、署名時にメッセージのヘッダーフィールドの実際の数よりも1回だけリストする必要があります。たとえば、署名時に単一のコメントヘッダーフィールドがある場合、「h =」タグにコメントを2回リストするだけで、コメントヘッダーフィールドがいくつも追加されるのを防ぐことができます。 「h =」タグにコメントを3回以上リストする必要はありません（ただし正当です）。
Refer to Section 5.4.2 for a discussion of the procedure to be followed when canonicalizing a header with more than one instance of a particular header field name.
特定のヘッダーフィールド名の複数のインスタンスを使用してヘッダーを正規化する場合に従う手順については、セクション5.4.2を参照してください。
Signers need to be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or otherwise reordered. Trace header fields (such as Received) and Resent-* blocks are the only fields prohibited by [RFC5322] from being reordered. In particular, since DKIM-Signature header fields may be reordered by some intermediate MTAs, signing existing DKIM-Signature header fields is error-prone.
署名者は、配信プロセスの後半で追加のインスタンスが追加される可能性のあるヘッダーフィールドの署名に注意する必要があります。 [Received]などのトレースヘッダーフィールドとResent- *ブロックは、[RFC5322]によって並べ替えが禁止されている唯一のフィールドです。特に、いくつかの中間MTAによってDKIM-Signatureヘッダーフィールドが並べ替えられる可能性があるため、既存のDKIM-Signatureヘッダーフィールドへの署名はエラーが発生しやすくなります。
INFORMATIVE ADMONITION: Despite the fact that [RFC5322] does not prohibit the reordering of header fields, reordering of signed header fields with multiple instances by intermediate MTAs will cause DKIM signatures to be broken; such antisocial behavior should be avoided.
有益な警告：[RFC5322]はヘッダーフィールドの並べ替えを禁止していないという事実にもかかわらず、中間MTAによる複数のインスタンスで署名済みヘッダーフィールドの並べ替えを行うと、DKIM署名が壊れます。そのような反社会的行動は避けるべきです。
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this specification, all end-user visible header fields should be signed to avoid possible "indirect spamming". For example, if the Subject header field is not signed, a spammer can resend a previously signed mail, replacing the legitimate subject with a one-line spam.
有益なIMPLEMENTERの注：この仕様では必須ではありませんが、「間接的なスパム」の可能性を避けるために、すべてのエンドユーザーに表示されるヘッダーフィールドに署名する必要があります。たとえば、件名ヘッダーフィールドが署名されていない場合、スパマーは以前に署名されたメールを再送信して、正当な件名を1行のスパムに置き換えることができます。
5.4.2. Signatures Involving Multiple Instances of a Field
Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the "h=" tag of the DKIM-Signature header field and MUST sign such header fields in order from the bottom of the header field block to the top. The Signer MAY include more instances of a header field name in "h=" than there are actual corresponding header fields so that the signature will not verify if additional header fields of that name are added.
メッセージ内で複数回発生する既存のヘッダーフィールド（Receivedなど）に署名することを選択した署名者は、ヘッダーブロック内のそのヘッダーフィールドの物理的に最後のインスタンスに署名する必要があります。このようなヘッダーフィールドの複数のインスタンスに署名する署名者は、DKIM-Signatureヘッダーフィールドの「h =」タグにヘッダーフィールド名を複数回含める必要があり、ヘッダーフィールドブロックの下部から順にヘッダーフィールドに署名する必要がありますトップ。署名者は、「h =」に実際の対応するヘッダーフィールドよりも多くのヘッダーフィールド名のインスタンスを含めることができるため、その名前のヘッダーフィールドが追加されているかどうかは署名で検証されません。
INFORMATIVE EXAMPLE:
If the Signer wishes to sign two existing Received header fields, and the existing header contains:
Received: A
Received: B
Received: C
then the resulting DKIM-Signature header field should read:
DKIM-Signature: ... h=Received : Received :...
and Received header fields C and B will be signed in that order.
Re: Difference between AlwaysSignHeaders and OversignHeaders from lutz.niederer_at_gmx.net on 2012-06-19 (OpenDKIM Users mailing list)
Difference between AlwaysSignHeaders and OversignHeaders
古いバージョンの会話。このAlwaysSignHeadersは、おそらく今はないパラメタ。
ここで、OversignHeadersの説明があり。
AlwaysSignHeaders (ASH) will add exactly one header field. So, if this header field is set then it will be included in the signature with its value. If it is not set then it will be included in the signature with its value of null. So it makes sure that nobody modifies the field if it exists or adds the field if it does not exist. But if it exists and someone adds this specific field a second time (downstream) then the signature is still ok as it accounts for the first field only and "does not see" the second field.
AlwaysSignHeaders（ASH）は、ヘッダーフィールドを1つだけ追加します。そのため、このヘッダーフィールドが設定されている場合は、その値とともに署名に含まれます。設定されていない場合、nullの値で署名に含まれます。そのため、フィールドが存在する場合は誰もフィールドを変更せず、存在しない場合はフィールドを追加しません。しかし、それが存在し、誰かがこの特定のフィールドを2回（下流）追加した場合、最初のフィールドのみを説明し、2番目のフィールドを「見えない」ので、署名は大丈夫です。
If I would like to make sure that only the exact number of fields that I put into the header travel down the road then I should use OversignHeaders (OSH). It takes all of the named fields at the time of signing and puts them n+1 times into the header "h=" (and the signature). The "+1" is used for a final empty header of that name to close the list. Means nobody can add a header without being detected because that delimiting last header is not empty anymore and the signature verification would fail.
ヘッダーに入力したフィールドの正確な数だけが道を進むようにする場合は、OversignHeaders（OSH）を使用する必要があります。署名時にすべての名前付きフィールドを取得し、ヘッダー「h =」（および署名）にn + 1回挿入します。 「+1」は、リストを閉じるためにその名前の最後の空のヘッダーに使用されます。最後のヘッダーの区切りが空ではなくなり、署名の検証が失敗するため、誰も検出されずにヘッダーを追加できないことを意味します。
So, if you used OSH for signing Received headers and you had 3 Received lines at the moment of signing, you would find Received 4 times in the "h=" field and the 4th acts as a delimiter. If the mail travels on and gets some more Received headers it will finally fail signature verification. If I used ASH it will succeed the verification because it does not consider the ones added.
したがって、Receivedヘッダーの署名にOSHを使用し、署名の時点でReceived行が3行あった場合、「h =」フィールドにReceivedが4回見つかり、4番目が区切り文字として機能します。メールが送信され、さらにReceivedヘッダーを取得すると、最終的に署名の検証に失敗します。 ASHを使用した場合、追加されたものを考慮しないため、検証に成功します。
Means, in my case where I would like to make sure nobody modifies the header or adds the header if it does exist or if it does not exist I should use OSH and not ASH because with ASH someone could easily add that header a second time, what would be prohibited when using OSH.
つまり、誰かがヘッダーを変更したり、ヘッダーが存在する場合、または存在しない場合はヘッダーを追加しないことを確認したい場合、ASHでは誰かがそのヘッダーを簡単に2回追加できるため、ASHではなくOSHを使用する必要がありますOSHを使用するときに禁止されるもの。
And the Debian default of "OversignHeaders From" makes sure that no more of the From headers that I put into the message are added (normally one From, but two would be ok, too (if I put them in)).
Debianのデフォルトの「OversignHeaders From」は、メッセージに挿入したFromヘッダーが追加されないようにします（通常は1つのFromですが、2つでも構いません（それらを挿入する場合）。
