2016년 8월 22일 월요일

Sender Policy Framework

Sender Policy Framework

With Sender Policy Framework (sender policy framework), it is one of the transmission domain certification in the E-mail. It is a technique to detect whether the e-mail address of the sender does not pretend to be other domain names. I am called SPF or the SPF certification.

Table of contents

Summary

"The SMTP" used for an E-mail in the Internet can give its all the e-mail addresses of the sender freely. Because these spread as a virtual standard, I will come to the front as a security hole. An unwanted e-mail sender, the falsification of the sender address by so-called "spammer" were carried out in all parts of the world and were able to in this way trouble a user.

Therefore the discussion gradually got into full swing, and SPF came up as one of the measures. The falsification of the IP address is devised based on a premise to be difficult, and this can complete the certification just to acquire information listed on the principle DNS server. I can implement it easily to make the SPF-adaptive domain that I did by adding a postscript to the sentence structure called the SPF record for the zone file in the DNS server which the domain belongs to.

The SPF cannot defend all unwanted e-mails. Because it is "to detect whether I read a domain name listed in a sender address, and it is transmitted by a right email server" that SPF performs, I cannot detect the unwanted e-mail that does not falsify a sender address although there is an effect for the phishing that went by way of the E-mail which, for example, pretended to be domains such as a big company or the government. In addition, I cannot detect it in the SPF when I falsify only an account part, and the email transmission is possible in the same domain.

However, correspondence on the domain owner side may be relatively easy, and the SPF may say that the spread advances. In Japan, I am provided as one of the filtering services used by an E-mail led by a cell-phone company and it is called "spoofing attack email measures" other than "the domain certification" and spreads rapidly.

SPF record

The SPF is determined in RFC 7208, and the specifications are shown.

I show the general contents of the SPF record. I will declare the domain that the following contents were appointed saying "I want you to trust an E-mail sent by the IP address band which I appointed, but want you to refuse the E-mail from other IP address".

 v=spf1 +ip4:203.0.113.0/24 +ip4:198.51.100.0/24 -all

I really show the general contents of the zonal file which reflected an SPF record. I will declare the domain that the following contents were appointed saying "I want you to trust the E-mail sent by 203.0.113.1 or 203.0.113.2, but the E-mail from other IP address wants you to refuse it".

   :   :       IN MX 10 mail       IN TXT "v=spf1 +ip4:203.0.113.1 +ip4:203.0.113.2 -all"       IN A 203.0.113.1 mail IN A 203.0.113.2   :   :

It is recommended that I put the SPF record in less than 450 characters to maintain the compatibility with the old DNS server, but the TXT record of the DNS server needs attention in only 255 characters being able to fill it out per one. When there are a great many IP address bands sending an E-mail as an example and exceeds 255 characters, I close ダブルクウォート in the middle of a record as follows, and it is necessary to describe it while dividing it. I am just coupled, and the divided part is interpreted by a DNS server.

   :   :       IN MX 10 mail       IN TXT "v=spf1 "               "+ip4:203.0.113.0/28 +ip4:198.51.100.64/28 +ip4:192.0.2.16/28 "               "+ip4:203.0.113.128/28 +ip4:198.51.100.96/28 +ip4:192.0.2.48/28 "               "+ip4:203.0.113.144/28 +ip4:198.51.100.128/28 +ip4:192.0.2.160/28 "               "+ip4:203.0.113.160/28 +ip4:198.51.100.160/28 +ip4:192.0.2.176/28 "                "+ip4:203.0.113.192/28 +ip4:198.51.100.192/28 +ip4:192.0.2.240/28 "               "-all"       IN A 203.0.113.1 mail IN A 203.0.113.2   :   :

The domain that the following contents were appointed will declare, "I follow the description of the SPF record appointed in sp.example.jp and sp.example.com". I mention it later, but an item except ip4 ip6 all must not be beyond ten in 1 record.

   :   :       IN MX 10 mail       IN TXT "v=spf1 +ip4:203.0.113.2 include:sp.example.jp include:sp.example.com -all"       IN A 203.0.113.1 mail IN A 203.0.113.2   :   :

Theory

I refer to "the sender re-writing scheme"

The machine admitted that the SPF sends the E-mail for a certain domain formally makes it possible that a domain owner exhibits a thing (following sender policy) called one in TXT record of the DNS using an exclusive format. For example, as for the machine which does not admit that a sender address sends the E-mail which is over in "... @example.jp" formally, "example.jp" owner can appoint a thing called one. The delivery email server to inspect SPF can refuse the E-mail which arrived from a machine without authority before receiving the correspondence of the E-mail. Therefore, the theory is totally similar to the thing with the DNS blacklist (DNSBL: DNS-based Blackhole List) except that SPF uses authority commission of true Domain Name System.

The SPF protects an e-mail address of Return-Path which is the 'notify' party of the error email. I am informed the sender address in a beginning starting communication by the SMTP. The transmission former email server without the authority should send an error email to the e-mail address when transmission email server refuses the sender address. You should insert Return-Path header when transmission email server receives the sender address and accepts an address e-mail address and the correspondence successively again to maintain a sender address. The e-mail address of Return-Path often fits the sender e-mail address of the email header such as "From:" and "Sender:", but that's why there is not necessarily it. In addition, SPF is not a thing preventing these e-mail address falsification.

The spammer has the account of the domain that sender policy is listed in and can send an E-mail to do that I pass (Pass) to inspection of the SPF by misusing the system which became the crisis under the domain. In addition, it can send an E-mail passing inspection of the SPF to registered user even to go by way of an unjust certification server providing service letting the SPF certification from any sender address pass it. However, the unwanted e-mail made in that way can identify a transmission former email server easily.

The main advantage of the SPF is brought by the people whom an e-mail address is used for for falsification of Return-Path. Enormous error emails and other automatic reply emails that they do not ask for are sent, and they make it hard for it to use the E-mail commonly. If such people exhibit all IP addresses except it which performs failure (Fail) in inspection in an SPF record with a regular transmission IP address, delivery ahead email server to inspect SPF becomes able to refuse a falsification email, and the gross weight of the backscattering email decreases.

The SPF may bring profit more than a level to help the identification of the unwanted e-mail. When a sender in particular offers SPF information, I am connected and can use the result that the delivery email server passed inspection of the SPF for a white list to distinguish a known reliable sender. However, something like system and joint ownership email transmission system which became a crisis will limit this how to use.

Inspection failure and email transfer

When I declare the SPF record that a certain domain fails inspection, it is transmitted by the domain, and delivery is refused on the following conditions, and an error response can have possibilities to be returned to the fair E-mail which was transferred from delivery email server to a third party. (1)Unlike a mailing list, it is a characteristic of the SPF which the (3) forwarding address email server which does not exist is necessary for this inspecting SPF, and a transfer cause email server does it in a list of white of the (2) forwarding address email server which a transfer former email server does not transfer Return-Path to, and is clear. "Border" email server (behind email essence changer 〈 MX 〉), I cannot inspect SPF directly.of the delivery

The person with declaration becoming unacceptable as inspection of the SPF must accept a potential problem. They cannot demand that all delivery email server changes the transfer processing. In other words, one is clear in three at least serious conditions described here.

Technique called sender re-writing scheme (SRS) is a method for email transfer service to evade this problem.

HELO examination

For empty Return-Path used by an error email and other automatic reply emails, it may be said that SPF inspection by the HELO identity is almost duty. In "HELO mail.example.jp" and "EHLO mail.example.jp," I really inspect "postmaster@mail.example.jp" artificially.

The result that there is no SPF in (None) is useless in the false HELO identity, but, for effective host name, the SPF protects HELO identity. It was always coped as a choice for delivery email servers, and the last specifications that it was recommended that I always inspected HELO were included in the characteristic of this SPF with the later SPF draft again.

This enables it to refuse the white list of transmission former email servers based on passing HELO and all email servers failing HELO again. I can be used for a rating (レピュテーション) system. (a list of white and the blacklist are simple examples of the rating system)

Implementation

The implementation of the SPF consists of two parts.

I identify the email server which I recognized formally because a domain sends an E-mail on behalf of them. The domain adds this addition information to their existing DNS information. The delivery email server requires SPF information and can use it. As for the email server, it is generally done a cache for a performance enhancement of the DNS using a usual DNS inquiry. The delivery email server interprets information listed in SPF and acts according to the result.

In this way, specifications of the new DNS information that a domain sets it, and delivery email server uses are the core of the SPF. The SPF record is set in a standard DNS sentence structure as follows. example.jp. IN TXT "v=spf1 a mx -all"

"v=" defines the version of the used SPF. The following words prescribe mechanism (Mechanism) to use to be decided whether there is the qualification that a certain domain sends an E-mail to. "a" and "mx" show a computing system allowed to send an E-mail for a predetermined domain. If a previous system does not agree, "-all" in the last of the SPF record shows that the message should be refused.

Mechanism

Eight mechanism is defined.

all It is always the truth. As a result of being established, I am used for mechanism to take first priority for all IP addresses not to accord like "-all".
a When a domain name has A record (or AAAA record for IPv6) fitting it in the IP address of the transmission former email server, it becomes the truth (in other words, the E-mail arrives from a direct domain name).
ip4 When a transmission former email server is in the appointed IPv4 address range, it becomes the truth.
ip6 When a transmission former email server is in the appointed IPv6 address range, it becomes the truth.
mx When a predetermined domain name has MX record tied to the IP address of the transmission former email server, it becomes the truth (in other words, the E-mail arrives from one of email servers of the domains).
ptr When and I reverse pull that (Forward Confirmed reverse DNS), the IP address of the origin of transmission email server are included in the result that pulls plus, and did the reverse pull domain for the IP address of the transmission former email server, and a domain is over in an appointed domain name, it is the truth.
exists I perform an original pull in a predetermined domain name and become the truth in the presence of A record (regardless of the IP address).

This is hardly used only with an SPF macro language to use for more complicated collation like DNSBL.
include I take in a predetermined policy and become the truth when it passes inspection of the SPF. This is used normally to take in the policy of plural ISPs.

Limited child

I can associate each mechanism with one among four limited children.

  • "+" means a pass (Pass) of the inspection. I am used for an existing set price when I omitted a limited child, and "mx" is equal to "+mx".
  • I mean neutrality (Neutral) of the は inspection. When a policy is not appointed, I am interpreted like (NONE).
  • "~" means weak failure (SoftFail). It helps debug it between neutrality (Neutral) and failure (Fail).
  • "-" means failure (Fail). The E-mail should be refused (see below).

Modifier

The modifier considers future expansion of the SPF. So far, about two modifiers determined in RFC 7208, it was unfolded widely.

"exp=some.example.jp" gives a domain name in TXT record of the DNS. It is interpreted using a macrolanguage of the SPF to get explanation (generally a URL) of the failure (Fail) in addition to an SMTP error code. Most of these functions decorative excessively are not employed.

Instead of tying "all" to the SPF record of other domains, I can use "redirect=some.example.jp". It is easy how much this modifier is than I understand "include" which is similar mechanism.

Error processing

When SPF implementation detects the grammar error of the SPF record, you must stop an evaluation as a lasting error (PermError) promptly. The result cannot expect that I skip mechanism taking the wrong and continue it. Therefore, "include:bad.example" and "redirect=bad.example also" become "PermError".

As other safety measures, mechanism to refer to DNS namely every mechanism except "ip4" "ip6" "all" is limited by up to ten per SPF record. When an inquiry of a case and the DNS that an evaluation passes to for long time became the time-out by the SPF implementation, I can stop the evaluation as a temporary error (TempError). You must return a lasting error (PermError) when SPF needs an inquiry more than 10 directly or indirectly. "redirect= is also" counted for this processing restrictions.

"v=spf1 a -all" which is standard SPF declaration needs three times of DNS inquiries like (1)TXT record, (2) SPF record, (3)A or AAAA record. Because the number of this last DNS inquiries is a thing added up towards limit (10) by the first mechanism, and "all" does not need a DNS inquiry in this example, the first mechanism is the last.

Attention

When domains of the sender address (envelope sender displayed by Return-Path) are usually fair, I only confirm the SPF. The domain (e.g., virtual hosting) to share a transmission email server can give its separate domain names each. I do not confirm the SPF to function in network layer whether a predetermined E-mail really arrives from a person named a sender.

Refusal by the inspection failure

The declaration to fail inspection can become the effective thing, but is dangerous means. Therefore SoftFail may be declared (made for a limited study time) in substitution for Fail to evade danger. However, delivery email server refuses the E-mail which became Fail, and, as for the E-mail which became SoftFail, in SoftFail, it can be the thing which is more dangerous to the above than Fail by accepting you as a promising thing of the unwanted e-mail.

The behavior when I refused a transfer email is clear. In that case, the email server of the origin of transfer sends an error email to the e-mail address provided in Return-Path. The address that failed in explanation and the delivery of the SMTP error (the forwarding address) is included in a general error email (response). I imitate "551 User not local; please try <forwarding address address>" which is a normal SMTP error code, and the original sender detours around the email server of the transfer cause and can retransmit a direct E-mail to a forwarding address address.

However, the E-mail of SoftFail which I received as the thing which there is possibility of the unwanted e-mail in may be deleted by the final addressee. The user with the experience of the transfer setting not to consider SPF may easily delete it without confirming the thing which there is possibility of the unwanted e-mail in and a done E-mail carefully.

The same logic suggests that the delivery email server should catch the SPF suggestion to refuse a true inspection failure email. 迷惑メールの可能性がある物として検証不合格メールを受け入れることは、検証不合格メールを簡単に拒否する事よりさらに危険となり得る。 送信者ドメインにおいて検証に不合格となる宣言がされていて、それが何を意味するか知った上で宣言されていると期待できる場合は、検証不合格となったとしても、それは明らかにSPFを考慮しない転送設定により転送された物ではない。

検証地点

「境界」メールサーバ（メールエクスチェンジャ〈MX 〉）の背後でSPFを検証することは不可能ではない。通常、検証に関係する情報は、配送された電子メールにメールエクスチェンジャが追加した、Receivedヘッダ行に記される。しかしこの場合、検証不合格メールを拒否するのは非常に時間が掛かり、検証地点においては原則として検証不合格メールを削除することだけ可能である。

専門家はこの権利を得られるべきだが、プラグ・アンド・プレイができる状況ではない。したがってSPF仕様では、メールエクスチェンジャの後ではなく、SMTPセッション中のメールエクスチェンジャだけが、SPFの検証をすることが推奨されている。もしSPFレコードの宣言者が彼らの方針の改善を計画する時に、一緒にDNSキャッシュの満了を考慮して慎重に計画しないと、メールエクスチェンジャの後でSPFを検証することは予想外の結果を得ることもある。

DoS攻撃

2006年のIETF Internet-Draft（SPFがDoSを引き起こす危険性〈SPF DoS Exploitation 〉）では、SPFに関するDNS回答の規模によっては、SPFをDNSへ打撃を与える手段とするネットワーク攻撃に繋がるという懸念について議論された。この問題は、SPFに関するRFCの「セキュリティに関する考察」（Security Considerations）でも取り上げられている。SPFプロジェクトはこの草案の詳細な分析を行い、SPFはDNSサービス拒否攻撃の原因とならないという結論を下した。

この結論で見落とされていることは、SPFの機構は10個までに制限されているが、それぞれの機構が名前解決をするごとに10個のDNS問合せが行われ、攻撃対象に対して合計100個の問合せを一度に引き起こすかもしれないということである。その上、送信者アドレスのlocal-part（@の左側部分）に展開されるマクロ文字は、それ以降の問合せを無作為化するために用いることができるため、スパマーの資源は何も消耗されない。そのようなネットワーク通信は、DNSは問合せより回答の方がデータ量が多い（つまりデータ量を増幅させる）という特性を悪用した攻撃（DNS amplification attack）を無限に引き起こすことを意味する。この起こり得る弱点の重大性は他の通信規約（ネットワーク・プロトコル）ではみられない物である。

歴史

2003年に開催されたYAPC（Yet Another Perl Conference）とOSCON（O'Reilly Open Source Convention）において、SPFの概念が紹介された。2002年にポール・ヴィクシー（Paul Vixie）により著された"Repudiating Mail-From"（『Mail-Fromの否認』）という短い論説である。その前身は、Hadmut Danischによる"Reverse MX"（RMX）と、Gordon Fecykによる"Designated Mailer Protocol" （DMP）であった。

2003年6月、メン・ウェン・ウォン（Meng Weng Wong）はRMXとDMP仕様を融合し、他のプログラマからの提案を求めた。その後6ヶ月以上に渡り多くの改良が為され、コミュニティはSPFの取り組みを始めた。

当初、SPFは"Sender Permitted From"の略であり、時には"SMTP+SPF"とも呼ばれた。その後2004年2月には、SPFの正式名称が"Sender Policy Framework"に変更された。

2004年前半には、Internet Engineering Task ForcIETFはMARID（MTA Authorization Records in DNS）ワーキンググループを組織し、SPFとマイクロソフトのCallerID提案を基にして、現在Sender IDとして知られていることの制定を試みた。

しかしMARIDによる検討が失敗に終わり、SPFコミュニティは元の"Classic"バージョンのSPFに立ち返り、RFC化を目指すことを決定した。2005年7月にはClassicバージョンの仕様がIETF experimentとしてIESGにより承認、そして2006年4月28日、SPFはRFC 4408としてRFC化された。

論争

2004年1月5日、スティーヴン M. ベロヴィン（Steven M. Bellovin）は長い電子メールを書き、SPFに関する幾つかの懸念について議論した。それは次のような内容だった。

  • SPFはDNSのTXTレコードを使うが、TXTレコードは特別な意味を持たない自由形式の文章であることが想定されている。SPFの支持者は、SPF用に明確に指定されたレコードを持つ方が良いと直ちに肯定するが、その選択はSPFの迅速な実装を可能にした。2005年7月、IANAはSPFにtype 99の資源レコードを割り当てた。SPFを宣言する者は両方のレコード型で宣言する可能性があり、SPFの検証ソフトはそれぞれの型を検証する可能性がある。全てのDNSソフトがこの新しいレコードに完全に対応するまで、何年も掛かることが予想される。

彼がこの声明文を書いた時は、これが正しい方法であるという合意はなかった。幾つかの主要なメールサービス業者はこの理論に同意しなかった。多くの利用者を抱える主要なメールサービス業者が対応するまで、それらのメールサービスを直接利用する者や、それらのメールサービスのドメインを詐称した電子メールを受け取る者に対して、SPFはあまり効果を上げることができない。SPFに対する関心が高まった時から、特にAOLがSPFを採用した点に注目する価値がある。

  • ベロヴィンの最も強い懸念は、SPFの根底にある前提（SPFの「意味論モデル」）に関連する物であった。SPFを使う時、どのように電子メールが送信されることが許されるのかということを、SPFのDNSレコードは決定する。つまり電子メールの送信方法についてドメインの所有者が制御することになる。（例えば、医師や弁護士などの専門家に対して作られたメールアドレスなど）個人が移動する先々で使える「携帯型」のメールアドレスを使う人は、メール送信に用いるメールサーバのドメインを送信者アドレスとして使うことが必須となっている。しかしその送信者アドレスはすでに存在しないかも知れない。それらの「携帯型」メールアドレスを提供している組織は、その組織が自らMail Submission Agent（MSA）（RFC 4409）やVirtual Private Network（VPN）を用意するということもあり得る。またSPFはメール送信を許されたMSAにSMTPのReturn-Pathを関係付けるだけであり、利用者が別の場所で発行された自分のメールアドレス（RFC 2822）[1]を使うことは自由なままである。

Jonathan de Boyne Pollardは、SPFが電子メールに関するRFCと矛盾するという議論において、SPFに反対して別の痛烈な非難を書いた。ISPの顧客に特定の方法で電子メールを使用させることをISPに押し付けることと、転送時の問題がSPFの能力である。

配備

その限界にもかかわらず、多くの人はSPFの利点がその欠点に勝ることを確信し、SPFの実装を始めた。SpamAssassin version 3.0.0やAnti-Spam SMTP Proxy（ASSP）といった迷惑メール対策ソフトウェアがSPFに対応した。多くのメールサーバ（MTA: Message Transfer Agent）は、CommuniGate Pro、Wildcat、Microsoft Exchange、SmarterMailのように直接SPFに対応したり、またPostfix、Sendmail、Exim、qmailのように修正パッチやプラグインの形でSPFに対応した。Amazon、AOL、EBay、Google、GMX、Hotmail、マイクロソフト、W3Cといった多くの有名なドメインは、2004年中頃にはSPFデータを宣言することを決めた。

2007年に発表された調査によると、.comドメインおよび.netドメインの5%が、何らかの送信者ポリシーが宣言されていた。ただしこれには「v=spf1 ?all」のように全く役に立たない宣言も含まれている可能性がある。[1]

日本における普及

現在、日本の下記携帯電話会社においてSPF認証が導入または導入予定である。ただし、その実装は標準とは一部異なり、検証の対象や条件は各社で異なる。

  • au - 「メールフィルター」サービスにおいて「ドメイン認証規制」[2]を選択可能。エンベロープFrom、それが存在しなければHELOドメインが検証の対象[3]となる。
  • DoCoMo - 「なりすましメール対策」を導入（2007年11月）。メールヘッダのFromフィールド、それが存在しなければエンベロープFromが検証の対象[4]となる。
  • SoftBank - 「なりすましメール拒否設定」が導入の予定[5]。

実効性

前述の通り、SPFは部分的にではあるものの、迷惑メールの防御に役立つと言われている。しかし、実効性には疑問の声がある。

  • 2005年には、SPFを逆手に取ったスパムが増加したことが報じられている[6]。これによると、スパムの9%はSPF認証に合格しているメールであり、そのうちの84%はスパム送信用に設けられたドメインであるという。つまり、登録ユーザーに対して任意の送信者アドレスからのSPF認証を合格させるようなスパム送信者用のドメインが横行しているということである。
  • 前述の通り、日本の一部の携帯電話会社ではSPF認証を導入している。しかし、2011年時点で設けられている仕組みは、SPF認証に合格したメールを許可し、合格しなかったものについて成りすまし判定を行うというものである。この仕組みでは、前項のように、スパム送信者用のドメイン経由で配信された、適当な送信者メールアドレスが付けられたSPF認証に合格したメールを許可することになってしまう。パソコンのメールにおいては過去より強固なフィルタリングルールが指定できるものが多く登場しており、そのようなものを使用すれば排除可能であるが、携帯メールについては左記の理由から、そうは言えない側面がある。
  • 前述の通り、SPFによって迷惑メールに対する追跡や法的な請求が容易になると言われている。しかし、SPFによって得られる情報は、送信者メールアドレスに対してSPF認証に合格したというお墨付きをあるメールサーバーが与えるだけのものである。そのメールサーバーを経由したというところまでの追跡は容易になるが、前述のような「登録ユーザーに対して任意の送信者アドレスからのSPF認証を合格させるようなスパム送信者用のドメイン」を経由した迷惑メールに対して、送信者を追跡できるだけの情報が得られるとは言えない。また、法的な請求については法的整備の範疇であり、SPFの守備範囲からは外れる。実際、日本においては特定電子メールの送信の適正化等に関する法律のような法的整備が行われているが、依然として迷惑メールの量は増加傾向にある[7]といった報告がある。

脚注

[ヘルプ]
  1. ^ 2008年10月、RFC 2822は、RFC 5322で置き換えられた。
  2. ^ "ドメイン認証規制". 2009年9月11日閲覧。
  3. ^ "送信ドメイン認証SPFレコードについて". 2009年9月11日閲覧。
  4. ^ "送信ドメイン認証（Sender ID／SPF）について". 2009年9月11日閲覧。
  5. ^ "「かんたん設定」の導入とブロック機能拡張について". 2009年9月11日閲覧。
  6. ^ "「Sender IDやSPFを逆手にとったスパムが増加」、米MX Logicの調査". 日経BP (2005年7月16日). 2011年6月24日閲覧。
  7. ^ "迷惑メールへの対応の在り方に関する研究会 最終とりまとめ". 2011年6月24日閲覧。

参考

外部リンク

「https://ja.wikipedia.org/w/index.php?title=Sender_Policy_Framework&oldid=57411701」から取得

This article is taken from the Japanese Wikipedia Sender Policy Framework

This article is distributed by cc-by-sa or GFDL license in accordance with the provisions of Wikipedia.

Wikipedia and Tranpedia does not guarantee the accuracy of this document. See our disclaimer for more information.

In addition, Tranpedia is simply not responsible for any show is only by translating the writings of foreign licenses that are compatible with CC-BY-SA license information.

0 개의 댓글:

댓글 쓰기

피드 구독하기: 댓글 (Atom)