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

Page 3

1.  Introduction
The practice of falsifying the identity of the sender of an e-mail
message, commonly called "spoofing", is a prevalent tactic used by
senders of unsolicited commercial e-mail, or "spam".  This form of
abuse has highlighted the need to improve identification of the
"responsible submitter" of an e-mail message.

1. はじめに

電子メールメッセージの送信者の身元を偽装する行為、俗に言う「なりすまし」は、未承諾広告電子メール、いわゆる「スパム」の送信者に広く使われている戦略だ。このような形の悪用がはびこっているため、電子メールメッセージの「責任を持つ投函者(Responsible Submitter)」表示を検討する必要が大きくなっている。

In this specification, the responsible submitter is the entity most
recently responsible for injecting a message into the e-mail
transport stream.  The e-mail address of the responsible submitter
will be referred to as the Purported Responsible Address (PRA) of the
message.  The Purported Responsible Domain (PRD) is the domain
portion of that address.

本定義中では、「責任を持つ投函者」とは、もっとも最近に電子メール伝送ストリームにメッセージを導入する責を負ったエンティティのことである。「責任を持つ投函者」の電子メールアドレスは、メッセージのPRA(Purported Responsible Address: 責任を持つはずのアドレス)として参照されることになる。PRD(Purported Responsible Domain: 責任を持つはずのドメイン)は、そのアドレスのドメイン部分である。

This specification codifies rules for encoding the purported
responsible address into the SMTP transport protocol.  This will
permit receiving SMTP servers to efficiently validate whether or not
the SMTP client is authorized to transmit mail on behalf of the
responsible submitter's domain.

本仕様では、SMTP転送プロトコルへのPRA符号化規則を定義する。これにより、SMTPクライアントが「責任を持つ投函者」のドメインを代表して電子メールを伝送する権限を持っているかについて、受信側SMTPサーバが効率的に検証できるようになる。

Broadly speaking, there are two possible approaches for determining
the purported responsible address: either from RFC 2821 [SMTP]
protocol data or from RFC 2822 [MSG-FORMAT] message headers.  Each
approach has certain advantages and disadvantages.

PRAの決定に使える方法は、おおまかに言って、RFC2821[SMTP]プロトコルデータと、RFC2822[MSG-FORMAT]メッセージヘッダの2種類が存在するが、それぞれの方法には長所と短所がある。

Deriving the purported responsible domain from RFC 2821 data has the
advantage that validation can be performed before the SMTP client has
transmitted the message body.  If spoofing is detected, then the SMTP
server has the opportunity, depending upon local policy, to reject
the message before it is ever transmitted.  The disadvantage of this
approach is the risk of false positives, that is, incorrectly
concluding that the sender's e-mail address has been spoofed.  There
are today legitimate reasons why the Internet domain names used in
RFC 2821 commands may be different from those of the sender of an e-
mail message.

RFC2821データからPRDを導出する方法には、SMTPクライアントがメッセージ本体を伝送する前に検証できるという長所がある。なりすましが検出されたら、SMTPサーバは、ローカルポリシに従って、メッセージが伝送される前に受け取りを拒否する機会を得られる。この方法の短所は、誤認定の危険性、すなわち、送信者の電子メールアドレスが偽装されていると誤った結論を出してしまうことだ。現状では、正当な理由のために、RFC2821コマンドで使われているインターネットドメイン名が電子メールメッセージの送信者ドメイン名と異なる可能性があるためである。

Deriving the purported responsible domain from RFC 2822 headers has
the advantage that validation can usually be based on an identity
that is displayed to recipients by existing Mail User Agents (MUAs)
as the sender's identity.  This aids in detection of a particularly
noxious form of spoofing known as "phishing" in which a malicious
sender attempts to fool a recipient into believing that a message
originates from an entity well known to the recipient.  This approach
carries a lower risk of false positives since there are fewer
legitimate reasons for RFC 2822 headers to differ from the true
sender of the message.  The disadvantage of this approach is that it
does require parsing and analysis of message headers.  In practice,
much if not all the message body is also transmitted since the SMTP
protocol described in RFC 2821 provides no mechanism to interrupt
message transmission after the DATA command has been issued.

RFC2822ヘッダからのPRD導出には、MUA(メールユーザエージェント)が受信者に対して送信者の身元として表示する身元に基づいて検証を行えるという長所がある。これは、特に「フィッシング」と呼ばれる有害な形式のなりすましの検出に有効だ。「フィッシング」とは、悪意のある送信者が受信者をだまして、受信者のよく知っているエンティティから出されたメッセージだと信じ込ませる手口である。この方法では、RFC2822ヘッダがメッセージの真の送信者と異なる正当な理由はずっと少ないため、誤認定の危険性は低い。この方法の短所は、メッセージヘッダの分析や解析が必要であることだ。実際、RFCに記述されているSMTPプロトコルはDATAコマンド発行後にメッセージ転送を中断する機構を提供していないため、メッセージ本体のほぼ全部が伝送されることになる。

[Page 3]

《PREV》
1 2 3 4 5 6 7 8 9 10 11 12 13 14

 
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先