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

Page 16

 
2.5.1.  Definition of Initial Methods

As they are currently existing specifications for message authentication, it is appropriate to define an authentication method identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID], and [SPF].  Therefore, the authentication method identifiers “auth”, “dkim”, “domainkeys”, “sender-id”, and “spf”, respectively are hereby defined for MTAs applying those specifications for email message authentication.

2.5.1.  初期方式の定義

[AUTH]、[DKIM]、[DOMAINKEYS]、[SENDERID]、[SPF]はメッセージ認証用として現在存在する仕様なので、そのそれぞれに認証方式識別子を定義するのが適切である。それゆえ、認証方式識別子“auth”“dkim”“domainkeys”“sender-id”“spf”がそれぞれ、電子メールメッセージ認証用に上記の仕様を適用しているMTAに対して定義される。

Furthermore, method “iprev” is defined in Section 3.

さらに、認証方式“iprev”が3章で定義される。

See Section 6 for details.

詳細については6章を参照のこと。

2.5.2.  Extension Methods

Additional authentication method identifiers (extension methods) may be defined in the future by later revisions or extensions to this specification.  Extension methods beginning with “x-” will never be defined as standard fields; such names are reserved for experimental use.  Method identifiers not beginning with “x-” MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC.  See Section 6 for further details.

2.5.2.  方式の拡張

追加の認証方式識別子(拡張方式)が将来本仕様の修正版または拡張によって定義されるかもしれない。“x-”で始まる拡張方式は標準フィールドとして定義されるものではない。このような名前は、実験での使用のために予約されている。“x-”で始まらない方式識別子はIANAで登録され、RFCとして公開されなければならない(MUST)。詳細については6章を参照のこと。

Extension methods may be defined for the following reasons:

拡張方式は以下のような理由で定義されることがある。

1.  To allow additional information from new authentication systems to be communicated to MUAs or downstream filters.  The names of such identifiers should reflect the name of the method being defined, but should not be needlessly long.

1 新しい認証システムからの追加情報をMUAや下流フィルタに通信できるようにするため。このような識別子の名前は定義されている方式の名前を反映すべきであるが、不必要に長くすべきではない。

2.  To allow the creation of “sub-identifiers” that indicate different levels of authentication and differentiate between their relative strengths, e.g., “auth1-weak” and “auth1-strong”.

2 様々なレベルの認証を示したり、それらの相対的強度を差別化する“sub-identifier”を生成できるようにするため。たとえば、“auth1-weak”と“auth1-strong”など。

Implementations of new methods MUST use the “x-” prefix until such time as the new method is registered by IANA.

新方式の実装は、新方式がIANAに登録されるまでは“x-”プレフィックスを使用しなければならない(MUST)。

Authentication method implementors are encouraged to provide adequate information, via [MAIL] comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results.  For example, if it might be of interest to relay what data was used to perform an evaluation, such information could be relayed as a comment in the header field, such as:

     Authentication-Results: example.com;
              foo=pass bar.baz=blob (2 of 3 tests OK)

認証方式の実装者は、MUA開発者の理解のため、または認証結果の補助的な詳細の中継を可能にするため、必要ならば[MAIL]コメントを通して、適切な情報を提供することが推奨される。たとえば、どんなデータが評価の実行に使われるのかを中継することが重要だとすれば、その情報を以下のようにヘッダフィールド内のコメントとして中継できるだろう。

     Authentication-Results: example.com;
              foo=pass bar.baz=blob (2 of 3 tests OK)

 

 [Page 16]

《PREV》 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 
 
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先