サイトマップ | 連絡先 | IAjapan TOP
IAjapan 財団法人インターネット協会
有害情報対策ポータルサイト 迷惑メール対策編
  • 一般利用者の皆様へ
  • メール管理者の皆様へ
  • 関連情報
  • サイト紹介

Page 3

1.  Introduction

DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream.  Message recipients can verify the signature by querying the Signer’s domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.

1. はじめに

DKIM(DomainKeys Identified Mail)は、電子メールメッセージに暗号を用いて署名する機構を定義している。この機構により、署名を行うドメインはメッセージをメール配送に導入する責任を主張できる。メッセージ受信者は署名者のドメインに直接問い合わせを行って適切な公開鍵を取得し、その署名を検証できる。そしてそれにより、署名を行うドメインに対する秘密鍵を所有する者によってそのメッセージが保証されたことを確認できる。

However, the legacy of the Internet is such that not all messages will be signed, and the absence of a signature on a message is not an a priori indication of forgery.  In fact, during early phases of deployment, it is very likely that most messages will remain unsigned.  However, some domains might decide to sign all of their outgoing mail, for example, to protect their brand names.  It might be desirable for such domains to be able to advertise that fact to other hosts.  This is the topic of Author Domain Signing Practices (ADSP).

しかし、インターネットの長年の状況から考えればすべてのメッセージが署名されるはずはないので、メッセージに署名がないことが無条件に偽装の印となるわけではない。実際、配備の早期段階中にはほとんどのメッセージが無署名のままである可能性が高い。しかし、たとえば自サイトの名前を守るなどのため、送出メールすべてに署名することを決定するドメインもあるかもしれない。そのようなドメインにとって、署名があるという事実を他のホストに通知できることが望ましいだろう。これがADSP(Author Domain Signing Practices)の主題である。

Hosts implementing this specification can inquire what Author Domain Signing Practices a domain advertises.  This inquiry is called an Author Domain Signing Practices check.

本仕様を実装するホストは、ドメインがどんなADSPを通知するかを問い合わせることができる。この問い合わせはADSP検証(ADSP check)という。

The basic requirements for ADSP are given in [RFC5016].  This document refers extensively to [RFC4871] and assumes the reader is familiar with it.


Requirements Notation:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].


 (訳注: 訳文では大文字部分の原文を( )内で示している。)

  “…してはならない(MUST NOT)”
  “(当然)…しないものとする(SHALL NOT)”
  “…すべきではない(SHOULD NOT)”
  “…を選択してもよい(OPTIONAL)” については、[RFC2119]の記述に従って解釈すること。

(編集者注: RFCの慣例では、SHALLとMUST、SHALL NOTとMUST NOTは同じ意味に使われる。)

2.  Language and Terminology

2.1.  Terms Imported from the DKIM Signatures Specification

Some terminology used herein is derived directly from [RFC4871].  In several cases, references in that document to “Sender” have been changed to “Author” here, to emphasize the relationship to the Author address(es) in the From: header field described in [RFC5322].

2.  専門用語

2.1.  DKIM署名仕様に由来する用語

(訳注:Authorとはメールの著者のことであるが、本翻訳では単に“著者” と訳す。)


o  A “Signer” is the agent that signs a message, as defined in Section 2.1 of [RFC4871].


・ [RFC4871]の2.1節で定義されているように、「署名者」はメッセージに署名するエージェントを指す。

[Page 3] 

1 3 5 7 10 13 16 17 18 20
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先