pikesaku’s blog





例) fromヘッダが途中MTAで追加され2つある場合



送信時点の署名対象: 送信時指定のFromの値
途中MTA追加後の署名対象: 送信時指定のFromの値(追加Fromの値は対象にならない)



送信時点の署名対象: 送信時指定のFromの値、Null(2個目ないので)
途中MTA追加後の署名対象: 送信時指定のFromの値、追加Fromの値


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


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


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.
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.
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.

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 =」に実際の対応するヘッダーフィールドよりも多くのヘッダーフィールド名のインスタンスを含めることができるため、その名前のヘッダーフィールドが追加されているかどうかは署名で検証されません。
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 (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.
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.
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つでも構いません(それらを挿入する場合)。



DKIM (Domainkeys Identified Mail) : 迷惑メール対策委員会
DMARC 詳細仕様-2 | なりすまし対策ポータル ナリタイ


DMARC レポートの受信を外部に委託する場合、すなわち DMARC レコードを設定したドメインと関係の無いドメインを rua や ruf に指定する場合には、相互の関連性を示す必要があります。

















  • 受信側は、受信メールに「DKIMヘッダなし」=「SPAMの可能性大」と判断できない。
  • DKIMヘッダあり検証OK」=「安心可能性大」は成立する。


Postfix before-queue Milterサポート

Postfix キューに入った後のコンテンツフィルタ



  • キューに入る前に処理するか?



  • OpenDKIMはMILTERを利用。


  • MILTERの方が新しい(2.3以降)
  • MILTER README冒頭には以下記述があり


Postfix バージョン 2.3 では Sendmail バージョン 8 の Milter (mail filter) プロトコルのサポートを導入します。
このプロトコルはMTAの外側のアプリケーションでメールの内容だけでなくSMTPのイベント (接続、切断)、SMTP コマンド (HELO、MAIL FROM など) を検査するのに使われます。これはすべてメールがキューに入る前におこなわれます

Postfix に Milter サポートを追加した理由は、望まないメールをブロックするだけでなく、信憑性を検証したり (例: SenderID+SPF と Domain keys)、メールに電子署名したり (例: Domain keys) といった既存アプリケーションがたくさんあるためです。
そういったもろもろのソフトウェアごとにもうひとつ Postfix 固有のバージョンを持つのは人的およびシステムのリソースの無駄遣いです。

例) Dr.Web(SPAM/ウイルス対策)は、どちらも対応
Anti-virus Dr.Web for UNIX mail servers


機能的にMILTER > FILTERであり、用途で使い分けるのでなく、MILTER対応してれば、MILTERを利用すべし